How to close a socket when all you have in an Apache::Connection object
I'm writing a protocol handler for mod_perl 2.0. If all I have is an Apache::Connection object, how can I tell Apache I want to close the connection? I tried sending an end of stream bucket down the bucket brigade, but that clearly did nothing. What's the canonical solution? Regards, Ken -- MailChannels: Control Your Email http://www.mailchannels.com Ken Simpson, CEO +1-604-729-1741 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
How to tell if there's data waiting on a NON-blocking Apache connection?
Oops -- the subject line was wrong last time. Let's try again: If all I have is an Apache::Connection object, is there a way to tell whether data is available from the connection's socket in the case where the connection has been put into nonblocking mode. Thanks, Ken -- MailChannels: Control Your Email http://www.mailchannels.com Ken Simpson, CEO +1-604-729-1741 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: How to tell if there's data waiting on a NON-blocking Apache connection?
> $c->client_socket gives you the socket object, now I suppose you want to > poll() it for read. Unfortunately we haven't exposed APR::Poll yet. Take a > look at the C API: > > http://lxr.webperf.org/source.cgi/srclib/apr/include/apr_poll.h > http://docx.webperf.org/apr__poll_8h.html > http://docx.webperf.org/group__apr__poll.html > > Is that what you are after? Yes, this is exactly what we need. Ideally, the APR interface should support the operations supported by IO::Select -- but it appears to. How much work is it to write the mappings for APR::Poll? I've never done it before but.. well we could give it a shot! TTUL Ken -- MailChannels: Control Your Email http://www.mailchannels.com Ken Simpson, CEO +1-604-729-1741 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: How to tell if there's data waiting on a NON-blocking Apache connection?
> the APR::Socket object is an opaque one, so it can't interoperate with any
> other perl modules. Have you looked if there is some C api to get the
> native socket object? There could be one (as they have for file objects),
> I didn't check.
I looked through apr_network_io.h, which seemed like the logical
place, and couldn't find an API that returns the native socket
object. But I'm pretty unfamiliar with the Apache code base, so
someone else would probably have better luck.
> >How much work is it to write the mappings for APR::Poll? I've never
> >done it before but.. well we could give it a shot!
>
> What C functions do you need to be exposed? it should be really quick if
> it can be exposed as is, without needing to write a special glue code...
The polling interface can poll files or sockets. For our application,
all we care about is sockets, but perhaps for completeness the
implementation should allow polling of files too.
These methods would need to be exposed to Perl:
apr_pollset_create -- Create a set of things to poll.
apr_pollset_add -- Add something to a set.
apr_pollset_remove -- Remove something from a set.
apr_pollset_poll-- Poll the set in a particular way.
apr_pollset_destroy -- Destroy the set.
We would also need to a way of filling in the apr_pollfd_t type
(i.e. polling file descriptor):
struct apr_pollfd_t {
apr_pool_t *p; /**< associated pool */
apr_datatype_e desc_type; /**< descriptor type */
apr_int16_t reqevents; /**< requested events */
apr_int16_t rtnevents; /**< returned events */
apr_descriptor desc;/**< @see apr_descriptor */
void *client_data; /**< allows app to associate context */
};
The desc field is a union that either contains a pointer to a socket
or a file (apr_file_t or apr_socket_t -- take your pick). The
client_data field is just a handy storage box for arbitrary data you
might want to use when you poll your file or socket.
And we'd also need this enum exposed as constants:
typedef enum {
APR_NO_DESC,/**< nothing here */
APR_POLL_SOCKET,/**< descriptor refers to a socket */
APR_POLL_FILE, /**< descriptor refers to a file */
APR_POLL_LASTDESC /**< descriptor is the last one in the list */
} apr_datatype_e ;
And of course some other #defines.
TTUL
Ken
--
MailChannels: Control Your Email
http://www.mailchannels.com
Ken Simpson, CEO
+1-604-729-1741
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: How to tell if there's data waiting on a NON-blocking Apache connection?
> This is what we'd need bound to the Perl API: > > apr_os_sock_t fd; > apr_os_sock_get((apr_os_sock_t *) &fd, (apr_socket_t *) client_socket); > > On Unix-type platforms, apr_os_sock_t is an int -- the file descriptor, > which you can use with select() or IO::Select() or anything you > like in Perl to poll the descriptor: Right on -- that would give us _everything_ we need. > To get the client socket for a connection, you can obtain the > (apr_socket_t *) with the incantation: > > apr_socket_t *client_socket = > ap_get_module_config(r->connection->conn_config, &core_module); > > and then use apr_os_sock_get() to get the fd. What would this incantation look like in Perl-land? TTUL Ken -- MailChannels: Control Your Email http://www.mailchannels.com Ken Simpson, CEO +1-604-729-1741 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: How to tell if there's data waiting on a NON-blocking Apache connection?
> >Right on -- that would give us _everything_ we need. > > but it'll work only on unix, isn't it? Yes -- that's right. It would be a unix-only solution. A more universal solution would be preferred -- i.e. supporting the APR::Poll interface. TTUL Ken -- MailChannels: Control Your Email http://www.mailchannels.com Ken Simpson, CEO +1-604-729-1741 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
mod_perl 1.99_16 tests fail on OpenBSD due to low open files limit
FYI, I just discovered after much pain and suffering that the mod_perl test suite fails to run on OpenBSD 3.5 because it tries to open more than 64 files at once. To duplicate, try this on your OpenBSD box: $ sudo ktrace -d /usr/local/apache2.0.50-modperl1.99_16/bin/httpd -d \ /export/src/mod_perl-1.99_16/t -f /export/src/mod_perl-1.99_16/t/conf/httpd.conf -D APACHE2 -X [Wed Aug 25 09:49:40 2004] [info] 26 Apache:: modules loaded [Wed Aug 25 09:49:40 2004] [info] 7 APR:: modules loaded [Wed Aug 25 09:49:40 2004] [info] base server + 20 vhosts ready to run tests [Wed Aug 25 09:49:40 2004] [error] Can't locate TestFilter/in_str_consume.pm in @INC (@INC contains: /export/src/mod_perl-1.99_16/t/lib /export/src/mod_perl-1.99_16/Apache-Test/lib /export/src/mod_perl-1.99_16/t/response /export/src/mod_perl-1.99_16/t/protocol /export/src/mod_perl-1.99_16/t/preconnection /export/src/mod_perl-1.99_16/t/hooks /export/src/mod_perl-1.99_16/t/filter /export/src/mod_perl-1.99_16/t /export/src/mod_perl-1.99_16/t/htdocs/testdirective/main /export/src/mod_perl-1.99_16/t/htdocs/testdirective/perlmodule-vh /export/src/mod_perl-1.99_16/t/ /export/src/mod_perl-1.99_16/t/lib/perl /export/src/mod_perl-1.99_16/blib/lib /export/src/mod_perl-1.99_16/blib/arch /usr/local/lib/perl5/5.8.4/OpenBSD.i386-openbsd /usr/local/lib/perl5/5.8.4 /usr/local/lib/perl5/site_perl/5.8.4/OpenBSD.i386-openbsd /usr/local/lib/perl5/site_perl/5.8.4 /usr/local/lib/perl5/site_perl/5.8.2/OpenBSD.i386-openbsd /usr/local/lib/perl5/site_perl/5.8.2 /usr/local/lib/perl5/site_perl) at (eval 65) line 3.\n [Wed Aug 25 09:49:40 2004] [error] Can't load Perl module TestFilter::in_str_consume for server localhost.orslut.com:8529, exiting... --- Perl can't load TestFilter/in_str_consume.pm because it can't open the file -- as evidenced in the ktrace dump: 16641 httpdNAMI "/export/src/mod_perl-1.99_16/t/lib/TestFilter/in_str_consume.pmc" 16641 httpdRET stat -1 errno 2 No such file or directory 16641 httpdCALL open(0x3cdae100,0,0) 16641 httpdRET open -1 errno 24 Too many open files This problem can be resolved by increasing the open file limit to 128: $ ulimit -n 128 I hope this helps someone down the road! Regards, Ken -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
[mp2] Protocol handler tests fail in 1.99_16 with Apache 2.0.50
en.xs, dlext=so, d_dlsymun=undef, ccdlflags=' ' cccdlflags='-DPIC -fPIC ', lddlflags='-shared -fPIC -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under openbsd Compiled at May 6 2004 19:19:56 %ENV: PERL_LWP_USE_HTTP_10="1" @INC: /usr/local/lib/perl5/5.8.4/OpenBSD.i386-openbsd /usr/local/lib/perl5/5.8.4 /usr/local/lib/perl5/site_perl/5.8.4/OpenBSD.i386-openbsd /usr/local/lib/perl5/site_perl/5.8.4 /usr/local/lib/perl5/site_perl/5.8.2/OpenBSD.i386-openbsd /usr/local/lib/perl5/site_perl/5.8.2 /usr/local/lib/perl5/site_perl . *** Packages of interest status: Apache::Request: - CGI: 3.04 LWP: 5.76 mod_perl : 1.9916 3. This is the core dump trace: (if you get a core dump): [CORE TRACE COMES HERE] This report was generated by t/REPORT on Wed Aug 25 22:14:03 2004 GMT. -- MailChannels: Control Your Email http://www.mailchannels.com Ken Simpson, CEO +1-604-729-1741 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl 1.99_16 tests fail on OpenBSD due to low open files limit
BTW -- just noticed that there's some documentation saying that the socket needs to be set to nonblocking mode to avoid this error (the "Resource temporarily unavailable" error). But the test scripts do set non blocking mode. I wonder if perhaps it's not working inside Apache? TTUL Ken Ken Simpson [25/08/04 09:54 -0700]: > FYI, I just discovered after much pain and suffering that the mod_perl > test suite fails to run on OpenBSD 3.5 because it tries to open more > than 64 files at once. > > To duplicate, try this on your OpenBSD box: > > $ sudo ktrace -d /usr/local/apache2.0.50-modperl1.99_16/bin/httpd -d \ >/export/src/mod_perl-1.99_16/t -f >/export/src/mod_perl-1.99_16/t/conf/httpd.conf -D APACHE2 -X > > [Wed Aug 25 09:49:40 2004] [info] 26 Apache:: modules loaded > [Wed Aug 25 09:49:40 2004] [info] 7 APR:: modules loaded > [Wed Aug 25 09:49:40 2004] [info] base server + 20 vhosts ready to run > tests > [Wed Aug 25 09:49:40 2004] [error] Can't locate TestFilter/in_str_consume.pm in @INC > (@INC contains: > /export/src/mod_perl-1.99_16/t/lib > /export/src/mod_perl-1.99_16/Apache-Test/lib > /export/src/mod_perl-1.99_16/t/response > /export/src/mod_perl-1.99_16/t/protocol > /export/src/mod_perl-1.99_16/t/preconnection > /export/src/mod_perl-1.99_16/t/hooks > /export/src/mod_perl-1.99_16/t/filter /export/src/mod_perl-1.99_16/t > /export/src/mod_perl-1.99_16/t/htdocs/testdirective/main > /export/src/mod_perl-1.99_16/t/htdocs/testdirective/perlmodule-vh > /export/src/mod_perl-1.99_16/t/ > /export/src/mod_perl-1.99_16/t/lib/perl > /export/src/mod_perl-1.99_16/blib/lib > /export/src/mod_perl-1.99_16/blib/arch > /usr/local/lib/perl5/5.8.4/OpenBSD.i386-openbsd > /usr/local/lib/perl5/5.8.4 > /usr/local/lib/perl5/site_perl/5.8.4/OpenBSD.i386-openbsd > /usr/local/lib/perl5/site_perl/5.8.4 > /usr/local/lib/perl5/site_perl/5.8.2/OpenBSD.i386-openbsd > /usr/local/lib/perl5/site_perl/5.8.2 /usr/local/lib/perl5/site_perl) at (eval 65) > line 3.\n > [Wed Aug 25 09:49:40 2004] [error] Can't load Perl module TestFilter::in_str_consume > for server localhost.orslut.com:8529, exiting... > > --- > > Perl can't load TestFilter/in_str_consume.pm because it can't open > the file -- as evidenced in the ktrace dump: > > 16641 httpdNAMI > "/export/src/mod_perl-1.99_16/t/lib/TestFilter/in_str_consume.pmc" > 16641 httpdRET stat -1 errno 2 No such file or directory > 16641 httpdCALL open(0x3cdae100,0,0) > 16641 httpdRET open -1 errno 24 Too many open files > > This problem can be resolved by increasing the open file limit to 128: > > $ ulimit -n 128 > > I hope this helps someone down the road! > > Regards, > Ken > > > -- > Report problems: http://perl.apache.org/bugs/ > Mail list info: http://perl.apache.org/maillist/modperl.html > List etiquette: http://perl.apache.org/maillist/email-etiquette.html > -- MailChannels: Control Your Email http://www.mailchannels.com Ken Simpson, CEO +1-604-729-1741 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl 1.99_16 tests fail on OpenBSD due to low open files limit
> >But the test scripts do set non blocking mode. I wonder if perhaps > >it's not working inside Apache? > > I'm not following you, Ken, what seems to be the problem? Non blocking mode is not actually being set despite the call to opt_set(). TTUL Ken -- MailChannels: Control Your Email http://www.mailchannels.com Ken Simpson, CEO +1-604-729-1741 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] Protocol handler tests fail in 1.99_16 with Apache 2.0.50
> Hmm, may be it reports blocking when it's not. What if you replace the > whole blocking testing/setting conditional block, with just unconditional: > > $socket->opt_set(APR::SO_NONBLOCK => 0); I have tried this and it makes no difference -- it looks like non blocking mode is simply not being set. I'm going to examine the diffs between Apache 2.0.49 and .50; this code worked properly on .49. I have a suspicion that something they did broke the OpenBSD build. Regards, Ken -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] Protocol handler tests fail in 1.99_16 with Apache 2.0.50
> >I have tried this and it makes no difference -- it looks like non > >blocking mode is simply not being set. > > And this verification code doesn't fail? > > # test that we really *are* in the blocking mode > !$socket->opt_get(APR::SO_NONBLOCK) > or die "failed to set blocking mode"; That's correct. Deep inside Apache, it is keeping track of the blocking modes as if they've been set but .. what it returns apparently does not reflect reality. I'm tracing through the Apache code to see what's actually happening. > I think it's this change that introduced this "feature": > > *) SECURITY: CAN-2004-0493 (cve.mitre.org) > Close a denial of service vulnerability identified by Georgi > Guninski which could lead to memory exhaustion with certain > input data. [Jeff Trawick] > > So you don't need to check all the differences. I think apr was affected > as well. Great. I'll look at the patch. There are no relevant diffs between 0.49 and 0.50 in the apr/network_io/unix/sockopt.c so the damage must have occurred somewhere else. > In fact APR is broken as it ignores the APR::BLOCK_READ flag in filters. > But nobody at httpd-dev/apr-dev seems to even care :( So filter writers > need to manually set the socket to the blocking mode, which sucks :( I agree. Of course, the deepest irony here is that what we actually should be doing for our application is writing APR::Poll support into mod_perl because Net::Server::Mail expects a non-blocking handle.. Thanks for the help. TTUL Ken -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] Protocol handler tests fail in 1.99_16 with Apache 2.0.50
> >I'm tracing through the Apache code to see what's actually happening. > > Ouch. > > Notice that apr-1.0 can be released any moment now. So please post a > notice to the apr-dev list if you find what the problem is. Okay -- I'll do that. > >Great. I'll look at the patch. There are no relevant diffs between > >0.49 and 0.50 in the apr/network_io/unix/sockopt.c so the damage must > >have occurred somewhere else. > > Please double check that (may be the httpd-dev archives), I could be > wrong. That patch only affects the HTTP protocol handler (http://www.apache.org/dist/httpd/patches/apply_to_2.0.49/CAN-2004-0493.patch) so I don't think it could be responsible for this behaviour. Also, I retested with 0.49 and the same problem is happening so.. who knows. > Yup, I'll be on the move starting tomorrow, so I'm not sure when I'll be > able to work on that. Ideally that should happen after 2.0 release, so we > don't get new TODO things on the way and first glean out the existing > ones. But feel free to work on those and we will help with any questions > that you may have (but better post them to the dev list, as they are more > technical than this list should care about). Okay -- sorry I didn't know there was a dev list. I'll subscribe to it. TTUL Ken -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] Protocol handler tests fail in 1.99_16 with Apache 2.0.50
> Oh, so may be it was always broken. Didn't you say that the problem was > introduced in Apache 2.0.50? It seemed that way, but I think that it actually died in 0.49. I'm trying with 0.48. TTUL Ken -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
APR::Poll support -- first cut
in a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+/* This is a very simplistic implementation of the APR::Poll interface.
+ * We only expose a bastardized version of the apr_poll() function, which
+ * in this case just allows you to poll one particular socket with
+ * a combination of polling options and a specified timeout.
+ *
+ * The pollset_* methods have not been included (they allow you to poll
+ * multiple sockets at one time. Nor has the ability to poll a file been
+ * provided because it's assumed that within, say, a protocol handler,
+ * you'd probably never need to.
+ *
+ * -- Ken Simpson, August 27, 2004. <[EMAIL PROTECTED]>
+ */
+
+static MP_INLINE
+int mpxs_apr_poll(pTHX_ SV *CLASS, apr_pool_t *pool,
+ apr_socket_t *socket, apr_interval_time_t timeout,
+ apr_int16_t reqevents)
+{
+ apr_pollfd_t fd;
+ apr_int32_t nsds;
+ apr_status_t rv;
+
+ /* Set up the aprset parameter, which tells apr_poll what to poll */
+ fd.desc_type = APR_POLL_SOCKET;
+ fd.reqevents = reqevents;
+ fd.rtnevents = 0; /* XXX: not really necessary to set this */
+ fd.p = pool;
+ fd.desc.s = socket;
+
+ /* Poll the socket */
+ rv = apr_poll(&fd, 1, &nsds, timeout);
+
+ return rv;
+}
diff mod_perl-1.99_16/xs/maps/apr_functions.map
mod_perl-1.99_16.withpoll/xs/maps/apr_functions.map
--- mod_perl-1.99_16/xs/maps/apr_functions.map Fri Aug 20 14:11:00 2004
+++ mod_perl-1.99_16.withpoll/xs/maps/apr_functions.map Fri Aug 27 21:46:41 2004
@@ -635,3 +635,8 @@
-apr_os_proc_mutex_put
-apr_os_shm_get
-apr_os_shm_put
+
+MODULE=APR::Poll
+ apr_poll | mpxs_ | \
+ SV *:CLASS, apr_pool_t *:pool, apr_socket_t *:socket, \
+ apr_interval_time_t:timeout, apr_int16_t:reqevents | poll
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: APR::Poll support -- first cut
> I was thinking, would it be better to make it an APR::Socket method? > > $socket->poll($c->pool, 1_000_000, APR::POLLIN); > > looks more intuitive to me. Especially since you've hardcoded the fd type > to be socket: > fd.desc_type = APR_POLL_SOCKET; That's a really good idea. I'll move it into the APR::Socket interface. And thanks for the advice on how to make a patch. Regards, Ken -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: APR::Poll support -- first cut
I have no problem removing the copyright from the patch. I will be changing the patch slightliy to implement Stas's suggestion of $socket->poll() instead of APR::Poll->poll(). When I submit that patch, there will be no copyright. Nonblocking sockets shall take precedence over hourly billing lawyers ;) Regards, Ken Joe Schaefer [28/08/04 20:17 -0400]: > Stas Bekman <[EMAIL PROTECTED]> writes: > > > in order to accept your code, it should be either posted here without any > > copyright notices in the post (which automatically makes it a public domain), > > > No, it doesn't: > > http://www.copyright.gov/fls/fl100.html > > ... Since the Berne Convention prohibits formal requirements that > affect the exercise and enjoyment of the copyright, the United States > changed its law on March 1, 1989 to make the use of a copyright notice > optional. > > IMO a patch containing a copyright notice is problematic because > it's no longer clear the author intends for it to be treated as > a typical contribution to the project. > > -- > Joe Schaefer > > > -- > Report problems: http://perl.apache.org/bugs/ > Mail list info: http://perl.apache.org/maillist/modperl.html > List etiquette: http://perl.apache.org/maillist/email-etiquette.html > -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] NetBSD-1.6.2 modperl 1.99_16 httpd 2.0.51-dev make test errors
> Ken, do you think this is somehow related to your recent patch in apr? > These tests didn't break before on NetBSD, is that correct, Mikhail? I'd put my $5.00 on APR being the cause of this problem. Mikhail, you will probably need to patch APR when you build Apache. Try this patch, which I am guessing will work on NetBSD: Index: build/apr_hints.m4 === RCS file: ./srclib/apr/build/apr_hints.m4,v retrieving revision 1.68 diff -u -r1.68 apr_hints.m4 --- build/apr_hints.m4 12 Aug 2004 13:44:29 - 1.68 +++ build/apr_hints.m4 27 Aug 2004 06:12:04 - @@ -131,6 +131,8 @@ ;; *-openbsd*) APR_ADDTO(CPPFLAGS, [-D_POSIX_THREADS]) +APR_SETIFNULL(ac_cv_o_nonblock_inherited, [yes]) ;; *-netbsd*) APR_ADDTO(CPPFLAGS, [-DNETBSD]) +APR_SETIFNULL(ac_cv_o_nonblock_inherited, [yes]) The problem is that the APR library thinks a socket is blocking by default -- when in fact the reverse is true on some platforms (on OpenBSD, for example). After applying this patch to your Apache, run ./buildconf to rebuild the configure script. Then run ./configure, make, make install. Let me know if it works for you and cc the Apache APR dev list. TTUL Ken -- MailChannels: Imagine no more spam -- http://www.mailchannels.com MailChannels Corporation Suite 1600, 1188 West Georgia St. Vancouver, BC, Canada Ken Simpson, CEO +1-604-729-1741 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] Test failures with APR::Socket
cw [06/09/04 13:50 +0100]: > Hey folks, > After a little delay due to other work getting in the way I'm back with > more questions. Make test is bailing out in a few places. Rather than > dump all the outputs here I've put them on my webspace: > > http://www.fidei.co.uk/files/mod_perl/ You are definitely experiencing the problem I discovered and fixed in APR not so long ago. Check out this message and its thread on the APR development list: http://article.gmane.org/gmane.comp.apache.apr.devel/6746 Bottom line: 1. Apply the patch. 2. Run ./buildconf, ./configure, make, make install 3. Re-test mod_perl. It should work. TTUL Ken -- MailChannels: Imagine no more spam -- http://www.mailchannels.com MailChannels Corporation Suite 1600, 1188 West Georgia St. Vancouver, BC, Canada Ken Simpson, CEO +1-604-729-1741 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] NetBSD-1.6.2 modperl 1.99_16 httpd 2.0.51-dev make test errors
> I wasn't surprised this fails on OpenBSD but I am surprised it fails on > NetBSD. Can you compile and run: > > http://www.apache.org/~jorton/nonblock.c > > and post the output. (it would be useful if you could do this on > OpenBSD too, Ken, for verification) -bash-2.05b$ ./nonblock connect: Invalid argument -- MailChannels: Imagine no more spam -- http://www.mailchannels.com MailChannels Corporation Suite 1600, 1188 West Georgia St. Vancouver, BC, Canada Ken Simpson, CEO +1-604-729-1741 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] NetBSD-1.6.2 modperl 1.99_16 httpd 2.0.51-dev make test errors
> >Ken, Stas, done as advised. The only test which is failing now (and was > >failing before) is: > > Mikhail, Ken, please submit that patch to dev /at/ apr.apache.org > http://apr.apache.org/. Hopefully it'll get into 2.0.51 release. Or may be > it's too late. The patch has already gone into APR CVS. TTUL Ken -- MailChannels: Imagine no more spam -- http://www.mailchannels.com MailChannels Corporation Suite 1600, 1188 West Georgia St. Vancouver, BC, Canada Ken Simpson, CEO +1-604-729-1741 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] NetBSD-1.6.2 modperl 1.99_16 httpd 2.0.51-dev make test errors
> So is that the right skip rule (hoping that 2.0.52 will fix NetBSD:
>
> my $should_skip =
> ($^0 eq /^OpenBSD$/i && !need_min_apache_version('2.0.51')) ||
> ($^0 eq /^NetBSD$/i && !need_min_apache_version('2.0.52'));
>
> and the tests that need to be skipped are:
>
> t/filter/both_str_con_add.t
> t/protocol/echo_block.t
> t/protocol/echo_filter.t
> t/protocol/pseudo_http.t
Yes, these tests break unless you have the APR patch. I don't know of
any others that also break.
TTUL
Ken
--
MailChannels: Imagine no more spam
--
http://www.mailchannels.com
MailChannels Corporation
Suite 1600, 1188 West Georgia St.
Vancouver, BC, Canada
Ken Simpson, CEO
+1-604-729-1741
Sent by MailChannels: http://www.mailchannels.com
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] NetBSD-1.6.2 modperl 1.99_16 httpd 2.0.51-dev make test errors
Sorry -- the APR patch for OpenBSD _did_ make it into the APR that is
tagged for release with 2.0.51.
http://cvs.apache.org/viewcvs.cgi/apr/build/apr_hints.m4?rev=1.53.2.9&only_with_tag=APACHE_2_0_51&view=auto:
...
*-openbsd*)
APR_ADDTO(CPPFLAGS, [-D_POSIX_THREADS])
# binding to an ephemeral port fails on OpenBSD so override
# the test for O_NONBLOCK inheritance across accept().
APR_SETIFNULL(ac_cv_o_nonblock_inherited, [yes])
...
I don't know about NetBSD or OSX.
TTUL
Ken
Stas Bekman [17/09/04 18:35 -0400]:
> Ken Simpson wrote:
> >>So is that the right skip rule (hoping that 2.0.52 will fix NetBSD:
> >>
> >>my $should_skip =
> >> ($^0 eq /^OpenBSD$/i && !need_min_apache_version('2.0.51')) ||
> >> ($^0 eq /^NetBSD$/i && !need_min_apache_version('2.0.52'));
> >>
> >>and the tests that need to be skipped are:
> >>
> >>t/filter/both_str_con_add.t
> >>t/protocol/echo_block.t
> >>t/protocol/echo_filter.t
> >>t/protocol/pseudo_httpt
> >
> >
> >Yes, these tests break unless you have the APR patch. I don't know of
> >any others that also break.
>
> You mean they still break OpenBSD with 2.0.51? I thought you said the
> patch was applied and entered 2.0.51. I'm at loss here. Should this just be:
>
> my $should_skip = $^0 eq /^(Open|Net)BSD$/i;
>
> for now?
>
> p.s. 2.0.51 was just released, not sure if you had a chance to test it.
>
> --
> __
> Stas BekmanJAm_pH --> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org http://ticketmaster.com
>
> Sent by MailChannels: http://www.mailchannels.com
--
MailChannels: Imagine no more spam
--
http://www.mailchannels.com
MailChannels Corporation
Suite 1600, 1188 West Georgia St.
Vancouver, BC, Canada
Ken Simpson, CEO
+1-604-729-1741
Sent by MailChannels: http://www.mailchannels.com
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl marketing
We have been using mod_perl successfully for several months now as a flexible email proxy -- we just wrapped Net::Server::Mail and with a few additional hacks and it worked. Matt Sergeant did the same thing with qpsmtpd and I have heard that the performance results were initially very promising (http://msgs.securepoint.com/cgi-bin/get/qmail0411/120/1/1/1.html). More details of our hack (patches etc.) are at http://www.mailchannels.com/opensource and http://search.cpan.org/~mock/Apache-SMTP-0.01/lib/Apache/SMTP.pm. IMHO, using mod_perl as a general application server is a great idea. For us there really was no other viable alternative. We looked at POE, Sendmail's milter API, Net::Server and of course qpsmtpd but the reliability, portability, and scalability of Apache was what caused us to go through the effort of making our bits work on mod_perl. To configure a mail server, it's just a matter of adding a VirtualHost section to the Apache configuration et voila. And as packages such as mod_throttle move over to Apache 2, we will gain the wonderment of a solid resource management tool for mail traffic. Joy! TTUL Ken Frank Wiles [30/11/04 13:30 -0600]: > On Tue, 30 Nov 2004 19:23:38 + > [EMAIL PROTECTED] wrote: > > > Please let me raise a question. > > > > In practice, people who can program in other phases usually can > > 1) program directly in C module; and 2) find that C provides > > much better a solution. > > > > For example, the authz phase in the dual-Apache setup. > > Here the static files are served by the light Apache. A C > > autenz handler is usually more efficient and may be a must. > > > > The same is true for the URL re-writing phase. Most likely we > > need the URL to be re-written for both dynamic contents and > > static files. > > > > So, while mod_perl is able to handle other phases, in practice, > > one may still need to go back to the C API for the best results. > > > > In the content phase, I think the OO programming, and so > > the MVC (Model-View-Control) concept, makes mod_perl > > much better a choice than PHP for large projects. > > I think you will find that mod_perl code is roughly the same > speed as a comporable C Apache module. Since mod_perl holds all of > the code in memory we don't have a fork/compile/excute problem which > is why most people think C is way faster than Perl. > > I've seen non response phase handlers, written in mod_perl, handle > better than commercial C modules. I'm curious why you think a C > module would be a better solution? > > - >Frank Wiles <[EMAIL PROTECTED]> >http://www.wiles.org > - > > > -- > Report problems: http://perl.apache.org/bugs/ > Mail list info: http://perl.apache.org/maillist/modperl.html > List etiquette: http://perl.apache.org/maillist/email-etiquette.html > > > Sent by MailChannels: http://www.mailchannels.com -- MailChannels: Assured Messaging -- Eliminate Critical False Positives http://www.mailchannels.com MailChannels Corporation Suite 1600, 1188 West Georgia St. Vancouver, BC, Canada Ken Simpson, CEO +1-604-729-1741 Sent by MailChannels: http://www.mailchannels.com -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl marketing
We have been using mod_perl successfully for several months now as a flexible email proxy -- we just wrapped Net::Server::Mail and with a few additional hacks and it worked. Matt Sergeant did the same thing with qpsmtpd and I have heard that the performance results were initially very promising (http://msgs.securepoint.com/cgi-bin/get/qmail0411/120/1/1/1.html). More details of our hack (patches etc.) are at http://www.mailchannels.com/opensource and http://search.cpan.org/~mock/Apache-SMTP-0.01/lib/Apache/SMTP.pm. IMHO, using mod_perl as a general application server is a great idea. For us there really was no other viable alternative. We looked at POE, Sendmail's milter API, Net::Server and of course qpsmtpd but the reliability, portability, and scalability of Apache was what caused us to go through the effort of making our bits work on mod_perl. To configure a mail server, it's just a matter of adding a VirtualHost section to the Apache configuration et voila. And as packages such as mod_throttle move over to Apache 2, we will gain the wonderment of a solid resource management tool for mail traffic. Joy! TTUL Ken Frank Wiles [30/11/04 13:30 -0600]: > On Tue, 30 Nov 2004 19:23:38 + > [EMAIL PROTECTED] wrote: > > > Please let me raise a question. > > > > In practice, people who can program in other phases usually can > > 1) program directly in C module; and 2) find that C provides > > much better a solution. > > > > For example, the authz phase in the dual-Apache setup. > > Here the static files are served by the light Apache. A C > > autenz handler is usually more efficient and may be a must. > > > > The same is true for the URL re-writing phase. Most likely we > > need the URL to be re-written for both dynamic contents and > > static files. > > > > So, while mod_perl is able to handle other phases, in practice, > > one may still need to go back to the C API for the best results. > > > > In the content phase, I think the OO programming, and so > > the MVC (Model-View-Control) concept, makes mod_perl > > much better a choice than PHP for large projects. > > I think you will find that mod_perl code is roughly the same > speed as a comporable C Apache module. Since mod_perl holds all of > the code in memory we don't have a fork/compile/excute problem which > is why most people think C is way faster than Perl. > > I've seen non response phase handlers, written in mod_perl, handle > better than commercial C modules. I'm curious why you think a C > module would be a better solution? > > - >Frank Wiles <[EMAIL PROTECTED]> >http://www.wiles.org > - > > > -- > Report problems: http://perl.apache.org/bugs/ > Mail list info: http://perl.apache.org/maillist/modperl.html > List etiquette: http://perl.apache.org/maillist/email-etiquette.html > > > Sent by MailChannels: http://www.mailchannels.com -- MailChannels: Assured Messaging -- Eliminate Critical False Positives http://www.mailchannels.com MailChannels Corporation Suite 1600, 1188 West Georgia St. Vancouver, BC, Canada Ken Simpson, CEO +1-604-729-1741 Sent by MailChannels: http://www.mailchannels.com -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Success Story
(I'm reposting this -- but in the format suggested on the success stories page; apologies for the spam) URL: http://www.mailchannels/opensource/ Title: Running email through mod_perl Contact Person: Ken Simpson <[EMAIL PROTECTED]> Traffic: Low (in development) Success Story: We have been using mod_perl successfully for several months now as a flexible email proxy -- we just wrapped Net::Server::Mail and with a few additional hacks and it worked. Matt Sergeant did the same thing with qpsmtpd and I have heard that the performance results were initially very promising (http://msgs.securepoint.com/cgi-bin/get/qmail0411/120/1/1/1.html). More details of our hack (patches etc.) are at http://www.mailchannels.com/opensource and http://search.cpan.org/~mock/Apache-SMTP-0.01/lib/Apache/SMTP.pm. IMHO, using mod_perl as a general application server is a great idea. For us there really was no other viable alternative. We looked at POE, Sendmail's milter API, Net::Server and of course qpsmtpd but the reliability, portability, and scalability of Apache was what caused us to go through the effort of making our bits work on mod_perl. To configure a mail server, it's just a matter of adding a VirtualHost section to the Apache configuration et voila. And as packages such as mod_throttle move over to Apache 2, we will gain the wonderment of a solid resource management tool for mail traffic. Joy! Regards, Ken -- MailChannels: Assured Messaging -- Eliminate Critical False Positives http://www.mailchannels.com MailChannels Corporation Suite 1600, 1188 West Georgia St. Vancouver, BC, Canada Ken Simpson, CEO +1-604-729-1741 Sent by MailChannels: http://www.mailchannels.com -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Debugging Out of Memory Errors
A module I wrote is somehow running out of memory and I need to find out why and where the problem is occurring. Searching through the archives, I discovered that in mod_perl 1.0 you could set the Apache::Debug level to 4: use Apache::Debug level => 4; (see the mod_perl book: http://modperlbook.org/html/ch22_03.html) Doing this would cause a special memory allocator to be used so that Carp could print out a stack trace in the event of an out of memory error. Is there an equivalent in mod_perl? Thanks, Ken -- MailChannels: Assured Messaging -- Eliminate Critical False Positives http://www.mailchannels.com MailChannels Corporation Suite 1600, 1188 West Georgia St. Vancouver, BC, Canada Ken Simpson, CEO +1-604-729-1741 Sent by MailChannels: http://www.mailchannels.com
Re: Debugging Out of Memory Errors
> Doing this would cause a special memory allocator to be used so that > Carp could print out a stack trace in the event of an out of memory > error. > > Is there an equivalent in mod_perl? Sorry -- I meant to say, "Is there an equivalent in mod_perl 2.0". Thanks, Ken -- MailChannels: Assured Messaging -- Eliminate Critical False Positives http://www.mailchannels.com MailChannels Corporation Suite 1600, 1188 West Georgia St. Vancouver, BC, Canada Ken Simpson, CEO +1-604-729-1741 Sent by MailChannels: http://www.mailchannels.com
Re: Debugging Out of Memory Errors
> >Is there an equivalent in mod_perl 2? > > I guess it wasn't on the todo list, so we have missed it while porting mp1 > core modules to mp2 It looks like it's trivial to port it to mp2. Feel > free to port that and post a patch to include it in the mp2 core, or > someone will do that later. I won't have time to do that work right now, but I'll consider it for a rainy day. Another question then: Is there a default pool size that is used to allocate the Perl interpreter in a mod_perl process? If so, can that size be increased? From tracing, it seems the out of memory is happening while allocating a ~3MB string within my module. That doesn't seem very large, but I thought perhaps there's a default that I'm trampling on. Thanks, Ken -- MailChannels: Assured Messaging -- Eliminate Critical False Positives http://www.mailchannels.com MailChannels Corporation Suite 1600, 1188 West Georgia St. Vancouver, BC, Canada Ken Simpson, CEO +1-604-729-1741 Sent by MailChannels: http://www.mailchannels.com
Re: [MP2] pseudo_http.pm tests fail under FreeBSD/Jail
cc='cc', ccflags ='-DAPPLLIB_EXP="/usr/public//lib/perl5/5.8.6/BSDPAN" > -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe > -I/usr/local/include', > optimize='-O -pipe ', > cppflags='-DAPPLLIB_EXP="/usr/public//lib/perl5/5.8.6/BSDPAN" > -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe > -I/usr/local/include' > ccversion='', gccversion='3.4.2 [FreeBSD] 20040728', gccosandvers='' > intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678 > d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 > ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', > lseeksize=8 > alignbytes=4, prototype=define > Linker and Libraries: > ld='cc', ldflags =' -Wl,-E -L/usr/local/lib' > libpth=/usr/lib /usr/local/lib > libs=-lm -lcrypt -lutil > perllibs=-lm -lcrypt -lutil > libc=, so=so, useshrplib=true, libperl=libperl.so > gnulibc_version='' > Dynamic Linking: > dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' > -Wl,-R/usr/public/lib/perl5/5.8.6/i386-freebsd-64int/CORE' > cccdlflags='-DPIC -fPIC', lddlflags='-shared -L/usr/local/lib' > > > Characteristics of this binary (from libperl): > Compile-time options: USE_64_BIT_INT USE_LARGE_FILES > Locally applied patches: > SUIDPERLIO0 - fix PERLIO_DEBUG local root exploit (CAN-2005-0155) > SUIDPERLIO1 - fix PERLIO_DEBUG buffer overflow (CAN-2005-0156) > Built under freebsd > Compiled at Feb 15 2005 07:22:27 > %ENV: > PERL_LWP_USE_HTTP_10="1" > @INC: > /usr/local/lib/perl5/site_perl/5.8.6/mach > /usr/local/lib/perl5/site_perl/5.8.6 > /usr/local/lib/perl5/site_perl > /usr/public//lib/perl5/5.8.6/BSDPAN > /usr/public/lib/perl5/5.8.6/i386-freebsd-64int > /usr/public/lib/perl5/5.8.6 > /usr/public//lib/perl5/site_perl/5.8.6/mach > /usr/public//lib/perl5/site_perl/5.8.6/i386-freebsd-64int > /usr/public//lib/perl5/site_perl/5.8.6 > . > > *** Packages of interest status: > > Apache2: - > Apache2::Request : - > CGI: 3.05, 3.10 > ExtUtils::MakeMaker: 6.17, 6.17 > LWP: 5.803 > mod_perl : - > mod_perl2 : 2.00 > > > 3. This is the core dump trace: (if you get a core dump): > > [CORE TRACE COMES HERE] > > This report was generated by /usr/local/bin/mp2bug on Thu Jun 2 15:02:50 > 2005 GMT. > > -8<-- End Bug Report --8<-- > > > > -- > Knowmad Services Inc. > http://www.knowmad.com > > > -- MailChannels: Assured Messaging -- Eliminate Critical False Positives http://www.mailchannels.com MailChannels Corporation Suite 1600, 1188 West Georgia St. Vancouver, BC, Canada Ken Simpson, CEO +1-604-729-1741 Sent by MailChannels: http://www.mailchannels.com
Re: [MP2] pseudo_http.pm tests fail under FreeBSD/Jail
> Can you tell me more about the bug you had? What does a "socket options > issue" mean? Do you know what ac_cv_o_nonblock_inherited is doing when > it gets set? What I remember is this: Deep inside APR, the socket module attempts to cache socket option information (such as blocking flags) in order to reduce the number of system calls made. On the OpenBSD platform, the state of a socket's non blocking flag was different from the initial state assumed (and cached) by APR. Because the initial cached copy was wrong, attempts to set the flag to the correct value would fail to cause an actual system call ... therefore the blocking state never actually changed. TTUL Ken -- MailChannels: Assured Messaging -- Eliminate Critical False Positives http://www.mailchannels.com MailChannels Corporation Suite 1600, 1188 West Georgia St. Vancouver, BC, Canada Ken Simpson, CEO +1-604-729-1741 Sent by MailChannels: http://www.mailchannels.com
Re: Version Control
Set yourself up with Subversion. It's easy to configure especially if you are running Apache 2 already and there is an excellent client for Windows (TortoiseSVN). If you're gung ho, you could even set up trac for issue tracking. It integrates really well with SVN and is a good solution for small to mid sized teams. Regards, Ken David Hofmann [27/07/05 12:22 -0400]: > > My company looking at setting up some kind of versioning control software. > Currently we have about 10 programs. We use Perl or C depending on the > project. > > I understand just enough to be dangerous with CVS. Which is the current > suggestion to use. However before we make use of it I want ask opinions. > > Most of our code goes on Apache Servers running on Redhat, however we use > Window XP machine for development. > > Any suggestions or comments would be appreciated. > > David > > _ > Express yourself instantly with MSN Messenger! Download today - it's FREE! > http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ > -- MailChannels: Assured Messaging -- Curious about my strange email address? Read more at http://www.mailchannels.com/domainaliasing.html Keep up with the latest insights in email security, phishing, and spam by reading the MailChannels blog at http://mailchannels.blogspot.com -- http://www.mailchannels.com MailChannels Corporation Suite 312, 1008 Homer St. Vancouver, BC, V6B 2X1, Canada 1-888-314-8904 x701
Re: UDP Protocol Handler?
Matt Sergeant [02/08/05 10:42 -0400]: > > On 20 Jul 2005, at 10:40, Dan Sully wrote: > > >Has anyone written a protocol handler for UDP? > > > >If so - could you share any examples? > > I haven't, but IIRC there is/was a talk at YAPC::EU about using > mod_perl as a DNS server... I think it is by mock, who did the mod_perl > as a mail server in Belfast last year. > > I guess that's not much help, except to know it's possible. Not to take too much of Will's glory, but yes, serving UDP in mod_perl is something that we are working on. BTW Matt: Have you released the super-caching DNS query system that you were discussing a few months back? The one that works way better than Net::DNS for doing nasty things like lots of SPF checks? Regards, Ken -- MailChannels: Assured Messaging -- Curious about my strange email address? Read more at http://www.mailchannels.com/domainaliasing.html Keep up with the latest insights in email security, phishing, and spam by reading the MailChannels blog at http://mailchannels.blogspot.com -- http://www.mailchannels.com MailChannels Corporation Suite 312, 1008 Homer St. Vancouver, BC, V6B 2X1, Canada 1-888-314-8904 x701
Re: go crazy with me
> Not sure what you mean by it not scaling - can you elaborate? Sure it > uses more ram than multiplexing, but even for a high traffic mail > server like apache.org's the mail-in-apache2 model works well > (apache.org uses Apache::Qpsmtpd for email). > > I'm curious as to how you've mixed things up though - if the details > aren't private IP I'd love to know more. I'll cut in so that Stas can save his keyboarding wrist. Our application requires establishing lots of very long running SMTP connections -- in busy sites, thousands. Most SMTP applications handle all connections in a short period of time, meaning the average process load is manageable. Our application selectively slows down connections, causing the connection load to go up even though the CPU isn't doing any more work. Since it's not possible within reasonable memory constraints to have thousands of Apache mod_perl processes resident, our application needs to be designed using an approach that can allow multiple SMTP connections per Perl process. Instead of having one multiprocessing-oriented Apache mod_perl process per SMTP connection, we use a single event-driven process to handle all SMTP connections. To avoid blocking in this single process, we dispatch any CPU-intensive tasks to a pool of Apache mod_perl processes via a simple TCP protocol. We also dispatch out any tasks which are difficult to re-program using asynchronous IO calls -- including calls out to libraries written by third parties (such as spam scanning engines). We are considering open sourcing the asyncronous API we built on top of Event::Lib when we have time to refactor the application to separate it from the application's proprietary parts. TTUL Ken -- MailChannels: Assured Messaging (TM) | http://mailchannels.com -- Suite 203, 910 Richards St. Vancouver, BC, V6B 3C1, Canada Direct: +1-604-729-1741
Solving mod_perl scalability issues for lots of slow connections
[note: Subject changed from "go crazy with me" -- LoL] > I'd also like to hear what people are doing when the apache model has > scaling problems. We have one problematic project here: we're a > gateway and must server a high number of very slow customers to a high > number of very slow feeds. Ideally we would run this in an event loop > or in coroutines/continuations style, but we have not yet tried that > out, mainly because so much of our infrastructure relies on everything > being apache. Is there something in apache2 that would make our lives > easier? (we have not yet switched to apache2 at all) Hi Andreas, I wonder if our asynchronous system could help. As I mentioned in a post earlier today, it's not yet released but we have been considering doing that perhaps in January when we have more time to polish it up for general consumption. Our email connection management software starts life as a mod_perl app, but forks a tiny Event::Lib based pure-Perl app after configuration to handle all the slow connections. A pool of mp2 processes is kept around, running a very simple protocol handler to receive and process short running but CPU-intensive requests from the IO subsystem. The nice thing about this architecture is that it still gives us access to the goodies mp2 has to offer -- such as application configuration -- while also allowing us to keep the number of Perl interpreters to a minimum by using a single process, event-driven IO model. Alas, if only the Perl interpreter was truly thread safe and did not clone a new interpreter for each thread, we could just use threads... Those Python people have it good in some ways. TTUL Ken -- MailChannels: Assured Messaging (TM) | http://mailchannels.com -- Suite 203, 910 Richards St. Vancouver, BC, V6B 3C1, Canada Direct: +1-604-729-1741
Re: go crazy with me
> Okay, so you basically run two daemons -- mod_perl, and a separate > multiplexing one -- to handle this? Did you investigate what would be > involved in changing apache to support multiplexing as an MPM? Yes -- we did look at that. The problem is that the MPM model assumes that the handler runs until it's finished and then dies -- i.e. in a single context of execution. To support an event driven model you would need to provide a way within the Apache API to allow the handler to post new event requests and return from handling without destroying the connection. i.e. the current Apache MPM model is: 1. Answer connection. 2. Call handler. 3. Handler runs. 4. Handler returns. 5. Disconnect. The event driven model would need to look something like this: 1. Answer connection. 2. Call handler. 3. Handler registers event callbacks on socket and returns. 4. ... MPM potentially answers other connections. ... time passes ... 5. Event occurs on socket. 6. Handler callback called. Handler may register another callback... ... time passes 7. Event occurs on socket. 8. Handler callback called. Handler decides the connection is over, and so disconnects from socket. 9. MPM goes on with life. TTUL Ken -- MailChannels: Assured Messaging (TM) | http://mailchannels.com -- Suite 203, 910 Richards St. Vancouver, BC, V6B 3C1, Canada Direct: +1-604-729-1741
