Re: session module
try a framework. that's much more popular. :) On Fri, Oct 29, 2010 at 8:20 PM, Perrin Harkins per...@elem.com wrote: Both work. CGI::Session was better maintained for a while but it looks like Apache::Session has been updated recently. Pick the one that you find easiest to understand from the documentation. - Perrin 2010/10/29 Jeff Pang jeff_p...@sina.com: is Apache::Session or CGI::Session better for mod_perl? Thanks. -- Fayland Lam // http://www.fayland.org/
Re: session module
于 2010-10-29 20:28, Fayland Lam 写道: try a framework. that's much more popular. :) I wrote a small application with few scripts. A framework like catalyst is too large to use for me. Thanks. Jeff.
Re: session module
于 2010-10-29 20:20, Perrin Harkins 写道: Both work. CGI::Session was better maintained for a while but it looks like Apache::Session has been updated recently. Pick the one that you find easiest to understand from the documentation. I know CGI::Session well. But have been thinking does Apache::Session get better performance under modperl? Thanks. Jeff.
Re: session module
try Dancer. which is very suitable for small application. just one file. Thanks On Fri, Oct 29, 2010 at 8:37 PM, Jeff Pang jeff_p...@sina.com wrote: 于 2010-10-29 20:28, Fayland Lam 写道: try a framework. that's much more popular. :) I wrote a small application with few scripts. A framework like catalyst is too large to use for me. Thanks. Jeff. -- Fayland Lam // http://www.fayland.org/
Re: session module
On Fri, Oct 29, 2010 at 8:39 AM, Jeff Pang jeff_p...@sina.com wrote: I know CGI::Session well. But have been thinking does Apache::Session get better performance under modperl? I haven't measured it, but I doubt there's any significant performance difference. Don't be fooled by the CGI in CGI::Session. - Perrin
Re: session module
于 2010-10-29 20:42, Fayland Lam 写道: try Dancer. which is very suitable for small application. just one file. Ok I will check out it. I first time knew Dancer from ruby 2 years ago. Never know that there is a perl execution of that.
Re: [mp2] Test failures with new Perls (patch included)
Can you pull the latest svn trunk and test against that version? 2.0.4 is about two years old and has several fixes applied to it. http://perl.apache.org/download/source.html On Fri, Oct 29, 2010 at 10:19 AM, Doug Schrag dsch...@oneupweb.com wrote: -8-- Start Bug Report 8-- 1. Problem Description: [mp2] Test failures with new Perls (patch included) Ref Message: Build fail on Ubuntu Sep 29, 2010 My issue is on a fresh install of CentOS 5.5 a. Authentication tests fail with LWP 5.815 and later Only test failures, induced by change to LWP * New versions of LWP preserve credentials across fetches with the same user agent. Attempts to test failure after successful authentication don't succeed (authentication succeeds when it should fail) * Apache::TestRequest provides a way to reset the user agent * Patched t/hooks/authen_basic.t and t/hooks/authz.t to reset the agent appropriately b. Apache2::Status crashes server during B::Concise test * Actual problem when Apache2::Status::noh_b_terse calls has($r,terse) * Test via status_config() emits a warning when StatusTerse config option is undefined * Warnings are FATAL, so server crashes * Patched Apache2/Status.pm so status_config() and sysdump() won't emit warnings [2.0.5-dev looks already patched for status_config() only] c. B::Concise test won't perform unless StatusTerse is set to ON * Patched t/conf/extra.conf.in as follows: Location /status/perl PerlSetVar StatusTerse On /Location * eval of B::Concise::compile in Apache2::Status::noh_b_terse now succeeds * t/logs/error_log then shows warning noise for the 'slow' test (non-fatal) * Don't know if this is backward-compatible or entirely correct 2. Used Components and their Configuration: *** mod_perl version 2.04 *** using /usr/local/src/apache/mod_perl-2.0.4/lib/Apache2/BuildConfig.pm *** Makefile.PL options: MP_APR_LIB = aprext MP_AP_PREFIX = /usr/local/apache2 MP_COMPAT_1X = 1 MP_GENERATE_XS = 1 MP_LIBNAME = mod_perl MP_USE_DSO = 1 *** /usr/local/apache2/bin/httpd -V Server version: Apache/2.2.17 (Unix) Server built: Oct 25 2010 16:25:37 Server's Module Magic Number: 20051115:25 Server loaded: APR 1.4.2, APR-Util 1.3.10 Compiled using: APR 1.4.2, APR-Util 1.3.10 Architecture: 32-bit Server MPM: Prefork threaded: no forked: yes (variable process count) Server compiled with -D APACHE_MPM_DIR=server/mpm/prefork -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) -D APR_USE_SYSVSEM_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D DYNAMIC_MODULE_LIMIT=128 -D HTTPD_ROOT=/usr/local/apache2 -D SUEXEC_BIN=/usr/local/apache2/bin/suexec -D DEFAULT_PIDLOG=logs/httpd.pid -D DEFAULT_SCOREBOARD=logs/apache_runtime_status -D DEFAULT_LOCKFILE=logs/accept.lock -D DEFAULT_ERRORLOG=logs/error_log -D AP_TYPES_CONFIG_FILE=conf/mime.types -D SERVER_CONFIG_FILE=conf/httpd.conf *** /usr/bin/ldd /usr/local/apache2/bin/httpd linux-gate.so.1 = (0x00ff) libm.so.6 = /lib/libm.so.6 (0x008c1000) libaprutil-1.so.0 = /usr/local/apache2/lib/libaprutil-1.so.0 (0x00f6f000) libexpat.so.0 = /usr/local/apache2/lib/libexpat.so.0 (0x00d04000) libapr-1.so.0 = /usr/local/apache2/lib/libapr-1.so.0 (0x00e0f000) libuuid.so.1 = /lib/libuuid.so.1 (0x03176000) librt.so.1 = /lib/librt.so.1 (0x0091c000) libcrypt.so.1 = /lib/libcrypt.so.1 (0x033c3000) libpthread.so.0 = /lib/libpthread.so.0 (0x008ec000) libdl.so.2 = /lib/libdl.so.2 (0x008ba000) libc.so.6 = /lib/libc.so.6 (0x0076) /lib/ld-linux.so.2 (0x00741000) *** (apr|apu)-config linking info -L/usr/local/apache2/lib -laprutil-1 -lexpat -L/usr/local/apache2/lib -lapr-1 -luuid -lrt -lcrypt -lpthread -ldl *** /usr/local/bin/perl -V Summary of my perl5 (revision 5 version 12 subversion 2) configuration: Platform: osname=linux, osvers=2.6.18-194.17.1.el5, archname=i686-linux uname='linux harriet.int.sodoit.com 2.6.18-194.17.1.el5 #1 smp wed sep 29 12:51:33 edt 2010 i686 i686 i386 gnulinux ' config_args='-de' hint=recommended, useposix=true, d_sigaction=define useithreads=undef, usemultiplicity=undef useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=undef, use64bitall=undef, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O2', cppflags='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include' ccversion='', gccversion='4.1.2
mod_perl 1.30 seg faults
I'm running a modperl installation with 1.30 and apache 1.3.42. I recently upgrade from Ubuntu 9.04 to Ubuntu 10.04 and now every time a mod perl process shuts, it dumps core. None of the application code changed. Maybe modperl isn't playing nicely with perl 5.10.1 (the old machine had 5.10.0)? Luckily it's not causing a problem since the core dump doesn't happen during a regular request. However it was fun watching the machine try to write 20gb of core dumps every few minutes Does anyone have any idea why this is happening or what I can do? I know 1.30 is old and apache 1.3.42 is end of life.Yes we will be upgrading to a newer version in the future, but I'm trying to find an interim solution over the next few months. Any help is much appreciated. Thanks! Brian Program terminated with signal 11, Segmentation fault. #0 0x4012ad6a in Perl_av_undef () from /usr/lib/libperl.so.5.10 (gdb) bt #0 0x4012ad6a in Perl_av_undef () from /usr/lib/libperl.so.5.10 #1 0x080842b0 in perl_shutdown (s=0xa09705c, p=0xd839a44) at mod_perl.c:284 #2 0x0808470a in perl_child_exit_cleanup (data=0xd839bd4) at mod_perl.c:940 #3 0x080c47dd in run_cleanups (c=0xd839bdc) at alloc.c:1703 #4 0x080c31e6 in ap_clear_pool (a=0xd839a44) at alloc.c:499 #5 0x080c325a in ap_destroy_pool (a=0xd839a44) at alloc.c:529 #6 0x080d12cd in clean_child_exit (code=0) at http_main.c:543 #7 0x080d340d in just_die (sig=15) at http_main.c:3258 #8 signal handler called #9 0x4001d422 in __kernel_vsyscall () #10 0x402c68ab in semop () from /lib/tls/i686/cmov/libc.so.6 #11 0x080d14f7 in accept_mutex_on_sysvsem () at http_main.c:895 #12 0x080d4ac7 in child_main (child_num_arg=0) at http_main.c:4589 #13 0x080d51d4 in make_child (s=0xa09705c, slot=0, now=1287622896) at http_main.c:5055 #14 0x080d526a in startup_children (number_to_start=5) at http_main.c:5083 #15 0x080d5a54 in standalone_main (argc=1, argv=0xbf8ab984) at http_main.c:5430 #16 0x080d632a in main (argc=1, argv=0xbf8ab984) at http_main.c:5773 (gdb)
Re: session module
--- On Fri, 10/29/10, Fayland Lam fayl...@gmail.com wrote: try Dancer. which is very suitable for small application. just one file. One file containing: use Dancer::Config; use Dancer::FileUtils; use Dancer::GetOpt; use Dancer::Error; use Dancer::Helpers; use Dancer::Logger; use Dancer::Plugin; use Dancer::Renderer; use Dancer::Response; use Dancer::Route; use Dancer::Serializer::JSON; use Dancer::Serializer::YAML; use Dancer::Serializer::XML; use Dancer::Serializer::Dumper; use Dancer::Session; use Dancer::SharedData; use Dancer::Handler; use Dancer::ModuleLoader; which isn't one file by my reckoning. Nevertheless, it looks very interesting. I will try a toy applet with it this weekend. Thanks for mentioning it. Phil On Fri, Oct 29, 2010 at 8:37 PM, Jeff Pang jeff_p...@sina.com wrote: 于 2010-10-29 20:28, Fayland Lam 写道: try a framework. that's much more popular. :) I wrote a small application with few scripts. A framework like catalyst is too large to use for me.
Re: mod_perl 1.30 seg faults
Hi Brian, That bug was fixed in mod_perl 1.31. Sure you can upgrade to last 1.x mod_perl. Regards. Salvador Ortiz. On 10/29/2010 02:50 PM, Brian Hirt wrote: I'm running a modperl installation with 1.30 and apache 1.3.42. I recently upgrade from Ubuntu 9.04 to Ubuntu 10.04 and now every time a mod perl process shuts, it dumps core. None of the application code changed. Maybe modperl isn't playing nicely with perl 5.10.1 (the old machine had 5.10.0)? Luckily it's not causing a problem since the core dump doesn't happen during a regular request. However it was fun watching the machine try to write 20gb of core dumps every few minutes Does anyone have any idea why this is happening or what I can do? I know 1.30 is old and apache 1.3.42 is end of life.Yes we will be upgrading to a newer version in the future, but I'm trying to find an interim solution over the next few months. Any help is much appreciated. Thanks! Brian Program terminated with signal 11, Segmentation fault. #0 0x4012ad6a in Perl_av_undef () from /usr/lib/libperl.so.5.10 (gdb) bt #0 0x4012ad6a in Perl_av_undef () from /usr/lib/libperl.so.5.10 #1 0x080842b0 in perl_shutdown (s=0xa09705c, p=0xd839a44) at mod_perl.c:284 #2 0x0808470a in perl_child_exit_cleanup (data=0xd839bd4) at mod_perl.c:940 #3 0x080c47dd in run_cleanups (c=0xd839bdc) at alloc.c:1703 #4 0x080c31e6 in ap_clear_pool (a=0xd839a44) at alloc.c:499 #5 0x080c325a in ap_destroy_pool (a=0xd839a44) at alloc.c:529 #6 0x080d12cd in clean_child_exit (code=0) at http_main.c:543 #7 0x080d340d in just_die (sig=15) at http_main.c:3258 #8signal handler called #9 0x4001d422 in __kernel_vsyscall () #10 0x402c68ab in semop () from /lib/tls/i686/cmov/libc.so.6 #11 0x080d14f7 in accept_mutex_on_sysvsem () at http_main.c:895 #12 0x080d4ac7 in child_main (child_num_arg=0) at http_main.c:4589 #13 0x080d51d4 in make_child (s=0xa09705c, slot=0, now=1287622896) at http_main.c:5055 #14 0x080d526a in startup_children (number_to_start=5) at http_main.c:5083 #15 0x080d5a54 in standalone_main (argc=1, argv=0xbf8ab984) at http_main.c:5430 #16 0x080d632a in main (argc=1, argv=0xbf8ab984) at http_main.c:5773 (gdb)
Re: session module
Haven't used any of the popular session modules in awhile. Are these susceptible to the cleartext cookie silliness exposed by FireSheep? Great Artists Ship Lon Koenig l...@schnoggo.com http://lonk.me http://lonkoenig.com On Fri, Oct 29, 2010 at 7:47 AM, Jeff Pang jeff_p...@sina.com wrote: 于 2010-10-29 20:42, Fayland Lam 写道: try Dancer. which is very suitable for small application. just one file. Ok I will check out it. I first time knew Dancer from ruby 2 years ago. Never know that there is a perl execution of that.
