Re: [ANNOUNCE] mod_perl 2.0.5
The word is 'pretty soon'. We're working out some of the release issues that slowed down the last release. You can always pull from subversion trunk and test with that version to see if it resolves the issue you are seeing. On Tue, Aug 23, 2011 at 6:19 PM, Hans Scharler wrote: > Any word on the release of mod_perl 2.0.6? > I will be glad to test to see if it solves the Apache restart issue when a > client stops the browser. > Thanks, > Hans > > On Mon, May 30, 2011 at 8:31 PM, Fred Moyer wrote: >> >> You might try pulling and building from svn trunk, Steve Hay fixed >> something that may be related. I don't have enough WinFoo to say for >> sure. Or wait another 4-6 weeks for 2.0.6. >> >> http://perl.apache.org/download/source.html >> >> =item 2.0.6-dev >> >> PerlIOApache_flush() and mpxs_Apache2__RequestRec_rflush() now no longer >> throw >> exceptions when modperl_wbucket_flush() fails if the failure was just a >> reset >> connection or an aborted connection. The failure is simply logged to the >> error >> log instead. This should fix cases of httpd.exe crashing when users press >> the >> Stop button in their web browsers. >> [Steve Hay] >> >> On Sun, May 29, 2011 at 7:56 PM, Hans Scharler >> wrote: >> > Yes, the entire process restarts. >> > Here is the exact line: >> > ModPerl::Util::exit: (12) exit was called at >> > D:/InterfaceServer/Perl/lib/CGI/Carp.pm line 561 >> > [Sun May 29 05:25:10 2011] [notice] Parent: child process exited with >> > status >> > 255 -- Restarting. >> > It's a notice. >> > I did some further testing and found that it restarts and exits apache >> > when >> > the application is printing to the browser. So, if you have a bunch of >> > data >> > to send to the browser and the connection stops in the middle, it throws >> > the above error. >> > my $template = "Lots of data .."; >> > print $template; >> > Is there a better way to transfer lots of data to the browser? >> > This is where I was able to to track it down to. If I stop the browser >> > before it hits this print line, the "ModPerl::Util::exit(0)" works. >> > Thanks fro taking a look. >> > Hans >> > >> > On Sun, May 29, 2011 at 3:07 PM, Thomas den Braber >> > wrote: >> >> >> >> Hans, >> >> >> >> > ModPerl::Util::exit: (12) exit was called at >> >> > D:/InterfaceServer/Perl/lib/CGI/Carp.pm line 561 >> >> > Parent: child process exited with status 255 -- Restarting. >> >> >> >> I have done a lot of testing on windows with the 2.05 release and have >> >> not >> >> seen this error before. It must be something specific in your code. It >> >> looks like the exit command is triggers some where in your code ( >> >> http://perl.apache.org/docs/2.0/api/ModPerl/Util.html#C_exit_ ). >> >> >> >> Does it also restart Apache? >> >> >> >> I have done some testing with calling ModPerl::Util::exit(0) (that's >> >> what >> >> is actually done in CGI::Carp) and did not found an error in my log. >> >> does >> >> it say [error] or [warn] in your log file ? >> >> >> >> -- >> >> Thomas >> >> >> >> >> > >> > > >
Re: [ANNOUNCE] mod_perl 2.0.5
Any word on the release of mod_perl 2.0.6? I will be glad to test to see if it solves the Apache restart issue when a client stops the browser. Thanks, Hans On Mon, May 30, 2011 at 8:31 PM, Fred Moyer wrote: > You might try pulling and building from svn trunk, Steve Hay fixed > something that may be related. I don't have enough WinFoo to say for > sure. Or wait another 4-6 weeks for 2.0.6. > > http://perl.apache.org/download/source.html > > =item 2.0.6-dev > > PerlIOApache_flush() and mpxs_Apache2__RequestRec_rflush() now no longer > throw > exceptions when modperl_wbucket_flush() fails if the failure was just a > reset > connection or an aborted connection. The failure is simply logged to the > error > log instead. This should fix cases of httpd.exe crashing when users press > the > Stop button in their web browsers. > [Steve Hay] > > On Sun, May 29, 2011 at 7:56 PM, Hans Scharler > wrote: > > Yes, the entire process restarts. > > Here is the exact line: > > ModPerl::Util::exit: (12) exit was called at > > D:/InterfaceServer/Perl/lib/CGI/Carp.pm line 561 > > [Sun May 29 05:25:10 2011] [notice] Parent: child process exited with > status > > 255 -- Restarting. > > It's a notice. > > I did some further testing and found that it restarts and exits apache > when > > the application is printing to the browser. So, if you have a bunch of > data > > to send to the browser and the connection stops in the middle, it throws > > the above error. > > my $template = "Lots of data .."; > > print $template; > > Is there a better way to transfer lots of data to the browser? > > This is where I was able to to track it down to. If I stop the browser > > before it hits this print line, the "ModPerl::Util::exit(0)" works. > > Thanks fro taking a look. > > Hans > > > > On Sun, May 29, 2011 at 3:07 PM, Thomas den Braber > wrote: > >> > >> Hans, > >> > >> > ModPerl::Util::exit: (12) exit was called at > >> > D:/InterfaceServer/Perl/lib/CGI/Carp.pm line 561 > >> > Parent: child process exited with status 255 -- Restarting. > >> > >> I have done a lot of testing on windows with the 2.05 release and have > not > >> seen this error before. It must be something specific in your code. It > >> looks like the exit command is triggers some where in your code ( > >> http://perl.apache.org/docs/2.0/api/ModPerl/Util.html#C_exit_ ). > >> > >> Does it also restart Apache? > >> > >> I have done some testing with calling ModPerl::Util::exit(0) (that's > what > >> is actually done in CGI::Carp) and did not found an error in my log. > does > >> it say [error] or [warn] in your log file ? > >> > >> -- > >> Thomas > >> > >> > > > > >
Re: [ANNOUNCE] mod_perl 2.0.5
You might try pulling and building from svn trunk, Steve Hay fixed something that may be related. I don't have enough WinFoo to say for sure. Or wait another 4-6 weeks for 2.0.6. http://perl.apache.org/download/source.html =item 2.0.6-dev PerlIOApache_flush() and mpxs_Apache2__RequestRec_rflush() now no longer throw exceptions when modperl_wbucket_flush() fails if the failure was just a reset connection or an aborted connection. The failure is simply logged to the error log instead. This should fix cases of httpd.exe crashing when users press the Stop button in their web browsers. [Steve Hay] On Sun, May 29, 2011 at 7:56 PM, Hans Scharler wrote: > Yes, the entire process restarts. > Here is the exact line: > ModPerl::Util::exit: (12) exit was called at > D:/InterfaceServer/Perl/lib/CGI/Carp.pm line 561 > [Sun May 29 05:25:10 2011] [notice] Parent: child process exited with status > 255 -- Restarting. > It's a notice. > I did some further testing and found that it restarts and exits apache when > the application is printing to the browser. So, if you have a bunch of data > to send to the browser and the connection stops in the middle, it throws > the above error. > my $template = "Lots of data .."; > print $template; > Is there a better way to transfer lots of data to the browser? > This is where I was able to to track it down to. If I stop the browser > before it hits this print line, the "ModPerl::Util::exit(0)" works. > Thanks fro taking a look. > Hans > > On Sun, May 29, 2011 at 3:07 PM, Thomas den Braber wrote: >> >> Hans, >> >> > ModPerl::Util::exit: (12) exit was called at >> > D:/InterfaceServer/Perl/lib/CGI/Carp.pm line 561 >> > Parent: child process exited with status 255 -- Restarting. >> >> I have done a lot of testing on windows with the 2.05 release and have not >> seen this error before. It must be something specific in your code. It >> looks like the exit command is triggers some where in your code ( >> http://perl.apache.org/docs/2.0/api/ModPerl/Util.html#C_exit_ ). >> >> Does it also restart Apache? >> >> I have done some testing with calling ModPerl::Util::exit(0) (that's what >> is actually done in CGI::Carp) and did not found an error in my log. does >> it say [error] or [warn] in your log file ? >> >> -- >> Thomas >> >> > >
Re: [ANNOUNCE] mod_perl 2.0.5
Yes, the entire process restarts. Here is the exact line: ModPerl::Util::exit: (12) exit was called at D:/InterfaceServer/Perl/lib/CGI/Carp.pm line 561 [Sun May 29 05:25:10 2011] [notice] Parent: child process exited with status 255 -- Restarting. It's a notice. I did some further testing and found that it restarts and exits apache when the application is printing to the browser. So, if you have a bunch of data to send to the browser and the connection stops in the middle, it throws the above error. my $template = "Lots of data .."; print $template; Is there a better way to transfer lots of data to the browser? This is where I was able to to track it down to. If I stop the browser before it hits this print line, the "ModPerl::Util::exit(0)" works. Thanks fro taking a look. Hans On Sun, May 29, 2011 at 3:07 PM, Thomas den Braber wrote: > Hans, > > > ModPerl::Util::exit: (12) exit was called at > > D:/InterfaceServer/Perl/lib/CGI/Carp.pm line 561 > > Parent: child process exited with status 255 -- Restarting. > > I have done a lot of testing on windows with the 2.05 release and have not > seen this error before. It must be something specific in your code. It > looks like the exit command is triggers some where in your code ( > http://perl.apache.org/docs/2.0/api/ModPerl/Util.html#C_exit_ ). > > Does it also restart Apache? > > I have done some testing with calling ModPerl::Util::exit(0) (that's what > is actually done in CGI::Carp) and did not found an error in my log. does > it say [error] or [warn] in your log file ? > > -- > Thomas > > >
Re: [ANNOUNCE] mod_perl 2.0.5
Hans, > ModPerl::Util::exit: (12) exit was called at > D:/InterfaceServer/Perl/lib/CGI/Carp.pm line 561 > Parent: child process exited with status 255 -- Restarting. I have done a lot of testing on windows with the 2.05 release and have not seen this error before. It must be something specific in your code. It looks like the exit command is triggers some where in your code ( http://perl.apache.org/docs/2.0/api/ModPerl/Util.html#C_exit_ ). Does it also restart Apache? I have done some testing with calling ModPerl::Util::exit(0) (that's what is actually done in CGI::Carp) and did not found an error in my log. does it say [error] or [warn] in your log file ? -- Thomas
Re: [ANNOUNCE] mod_perl 2.0.5
I have finally started testing mod_perl-2.0.5 on windows (both win 2003 / 2008). I compiled mod_perl using Visual Studio 2010 Express, Perl 5.10.1, and Apache 2.2.19. The reason that I wanted to use 2.0.5 of mod_perl was to resolve the issue with the Apache Process stopping. This was the original issue that I was able to repeat with 2.0.4 - http://www.gossamer-threads.com/lists/modperl/dev/102357 >From my testing, I still can stop the Apache process by stopping the browser in a middle of a connection. I used to have APR does not understand... Now, I have this error (instead of the APR error): ModPerl::Util::exit: (12) exit was called at D:/InterfaceServer/Perl/lib/CGI/Carp.pm line 561 Parent: child process exited with status 255 -- Restarting. We are going in the right direction, just need to figure out how to solve this new issue. Does anyone have any ideas on how to fix this? Thanks, as always. Hans On Wed, Feb 9, 2011 at 10:22 PM, Randolf Richardson wrote: > > Awesome everyone. Thanks for working on the new release of mod_perl. I > look > > forward to implementing it. > > This is great news! I'm very pleased to see this update because it > flies in the face of those who incorrectly insist that ModPerl is > dead because it hasn't been updated for a long time -- I've been > pointing out that the lack of updates are due to better quality code > and fewer change requirements. > >Thanks too all developers and contributors of ModPerl! I've been > hooked on this technology ever since I started using it, and I enjoy > the high performance and deep integration into APR and HTTPd. > > > Has anyone tried 2.0.5 on Windows? > > I haven't yet, but I look forward to trying it on NetBSD 5.1. I am > interested in trying it on Windows when a binary is available... > >I find that running ModPerl on Windows generally works well until > Perl scripts are changed frequently (and using the Reload module), > and then Apache HTTPd will either stop responding or just crash out > (especially if PerlMagick is in the mix). I wonder if this might be > an OS-specific problem thought since my Unix servers just don't > exhibit these symptoms. > > [End of reply.] > > > On Wed, Feb 9, 2011 at 6:12 PM, Jie wrote: > > > > > Thank you so much for the new release! > > > > > > Jie > > > > > > Please think of our environment and only print this e-mail if > necessary. > > > > > > * Andr? Warnier wrote: > > > > > > > Date: Tue, 08 Feb 2011 09:18:33 +0100 > > > > From: Andr? Warnier > > > > To: mod_perl Dev > > > > CC: mod_perl list > > > > Subject: Re: [ANNOUNCE] mod_perl 2.0.5 > > > > User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) > > > > > > > > Many thanks guys, for keeping mod_perl alive and well (and perl too > for > > > that matter). > > > > It is really a pity that not more people know how much their nice > > > > web applications depend on it. > > > > But then, maybe we should think that the people who matter, do know. > > > > > > > > > > > > Randolf Richardson - rand...@inter-corporate.com > Inter-Corporate Computer & Network Services, Inc. > Vancouver, British Columbia, Canada > http://www.inter-corporate.com > > >
Re: [ANNOUNCE] mod_perl 2.0.5 (and DBIx::Class auto-generated code)
On Sat, Feb 19, 2011 at 4:30 PM, Randolf Richardson wrote: > It's interesting to know that auto-generated code is a problem, and > this is providing me with some insight into why some DBIx::Class > users have been telling me that mod_perl (all versions) is so > terrible (I didn't experience the problems they described, and your > comment has shed some light on a possible reason). The sort of trouble I've seen with auto-generated code has to do with changing subs in ways that perl is unable to deal with without restarting the interpreter. For example, if you define a constant (which is a sub with a prototype in perl), and then change it and try to reload the module, you will have trouble. If you change the inheritance of a class, you may also have trouble. These things would be exactly the same under FastCGI or any other Perl environment. The problem is that Perl can't really reload classes on the fly, and tools that try to do it are simply deleting things from the symbol table and loading the code again. Sometimes this works and sometimes it doesn't, and the trickier your code is, the more likely it is to not work. Take people's prejudices against mod_perl with a grain of salt. There are many misconceptions out there about mod_perl, but when you run it in the recommended configuration (with a proxy server in front) there is very little real difference from FastCGI and friends. - Perrin
Re: [ANNOUNCE] mod_perl 2.0.5 (and DBIx::Class auto-generated code)
On Sat, Feb 19, 2011 at 1:30 PM, Randolf Richardson wrote: > It's interesting to know that auto-generated code is a problem, and > this is providing me with some insight into why some DBIx::Class > users have been telling me that mod_perl (all versions) is so > terrible (I didn't experience the problems they described, and your > comment has shed some light on a possible reason). For what it is worth, I've been using DBIx::Class with mod_perl for over five years now, and have not run into any problems worth mentioning. I separate my model code from my request handlers though, and increment the dependency version in my Makefile.PL, so I do a server restart whenever I update one of the dependent modules. The code separation causes the development process to take more time, but the code is usually better quality in my opinion. I build a model library with DBIx::Class autoloaders, to which I add custom methods for my model classes. Takes a lot of the book keeping work out of making accessor methods, etc.
Re: [ANNOUNCE] mod_perl 2.0.5 (and DBIx::Class auto-generated code)
> On Sat, Feb 12, 2011 at 3:26 PM, Thomas den Braber wrote: > > > On linux I also had never any problem with Reload. But on Linux I always > > run Apache with prefork MPM (I have not tested with Worker MPM on Linux > > yet), on Windows there is only Worker MPM, can there be a relation between > > the reload problem and the Worker MPM? > > Not likely. Threads don't share any data in Perl unless you tell them > to. The things Reload has trouble with tend to be sneaky programming > tricks, like auto-generated methods and classes. I never use the auto-generation feature in DBIx::Class from the web- server side -- I always generate these from a shell prompt first and then install them. I know there are a lot of people using DBIx::Class with auto- generation, probably because it's easier, but if something changes in the database then the class will change which could lead to some developers wondering what went wrong. It's interesting to know that auto-generated code is a problem, and this is providing me with some insight into why some DBIx::Class users have been telling me that mod_perl (all versions) is so terrible (I didn't experience the problems they described, and your comment has shed some light on a possible reason). Thanks! Randolf Richardson - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada http://www.inter-corporate.com
Re: [ANNOUNCE] mod_perl 2.0.5
On Sat, Feb 12, 2011 at 3:26 PM, Thomas den Braber wrote: > On linux I also had never any problem with Reload. But on Linux I always > run Apache with prefork MPM (I have not tested with Worker MPM on Linux > yet), on Windows there is only Worker MPM, can there be a relation between > the reload problem and the Worker MPM? Not likely. Threads don't share any data in Perl unless you tell them to. The things Reload has trouble with tend to be sneaky programming tricks, like auto-generated methods and classes. - Perrin
Re: [ANNOUNCE] mod_perl 2.0.5
> This is only happening to me on Windows though too, and just hasn't > been a problem under NetBSD running the same versions of Apache > HTTPd, APR, and Perl (although on the Windows side we're using > ActivePerl so perhaps that's a better culprit since NetBSD is using > Perl from pkgsrc?) with the same scripts. > On linux I also had never any problem with Reload. But on Linux I always run Apache with prefork MPM (I have not tested with Worker MPM on Linux yet), on Windows there is only Worker MPM, can there be a relation between the reload problem and the Worker MPM? --- Thomas den Braber
Re: [ANNOUNCE] mod_perl 2.0.5
> The only other times I can recall where I've experienced this > crashing is with the Apache2::Upload module, or with the > Image::Magick (PerlMagick) module (there are only a few instances > where I'm not using these two together). Even for test scripts where > I don't use "use base" at all, I can still get crashing with > Apache2::Reload after many script file changes, so I wonder if > Apache2::Upload depends on something that uses "use base" somewhere, > or if there's something common that it depends on that "use base" > also depends on? If so, then perhaps this points to the problem. I use PerlMagick and Apache2::Upload also. I never had problems with them. I use: PerlSetVar ReloadDirectories "/my_dev_dir" to only monitor my own modules and not any of the others (Apache2, PerlMagick, etc.). That causes less overhead (only about 10 ms per request for my ~60 modules) and maybe prevent other strange behaviour. -- Thomas den Braber
Re: [ANNOUNCE] mod_perl 2.0.5
> On 02/11/2011 12:02 PM, Randolf Richardson wrote: > > >> I use reload all the time it worked OK for most modules but some modules > >> (at least the ones that use "use base 'modulename';" ) will have problems. > > > > That's very interesting because where I'm seeing the crashing > > usually involves code that uses "use base" somewhere (in one > > particular case the base is for some basic database stuff that > > utilizes "DBIx::Class"-auto-generated code). > > I highly doubt that it's tied to "use base" at all, but instead is > caused by modules that are highly dynamic (do things like create methods > at runtime like DBIx::Class would do). But because this magic is buried > in the base class you don't see it until you use that base class as your > parent (via "use base"). Using any base class seems to be a common denominator when I'm experiencing these problems. It doesn't matter if DBIx::Class is in the picture or not either (there are also many scripts that don't interact with any databases). This is only happening to me on Windows though too, and just hasn't been a problem under NetBSD running the same versions of Apache HTTPd, APR, and Perl (although on the Windows side we're using ActivePerl so perhaps that's a better culprit since NetBSD is using Perl from pkgsrc?) with the same scripts. > Perl doesn't have a real way to unload a module or to completely force a > reload. Apache::Reload tries it's best but there are lots of modules it > can't handle. It's not it's fault really, it's a feature that's missing > in Perl. That's helpful information. At least on Unix I find that Apache2::Reload seems to be doing a good job of making this happen. Since I don't use Windows as production servers, this is mostly just an annoyance, but it would be nice to figure it out eventually. =) > These days, I never use Apache::Reload. I just restart my dev server ( > yes, I believe each dev should have their own dev Apache server). On Unix, I just restart as well since it's so quick, but on Windows I find that restarting is still slow (even on 64-bit Windows 7 which does this much faster than Windows XP) so I'll use Apache2::Reload for the first few times before restarting HTTPd -- usually the first few times don't result in any problems, and sometimes I can get away with 5 or 6 reloads before having to restart the HTTPd service. I agree that each developer should have their own server to crash and burn. I also like the idea of a pre-production "test" environment that is just like production since developer machines can often have extra libraries installed that don't exist on the production servers (that usually isn't as fun as people claim!). Randolf Richardson - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada http://www.inter-corporate.com
Re: [ANNOUNCE] mod_perl 2.0.5
On 02/11/2011 12:02 PM, Randolf Richardson wrote: I use reload all the time it worked OK for most modules but some modules (at least the ones that use "use base 'modulename';" ) will have problems. That's very interesting because where I'm seeing the crashing usually involves code that uses "use base" somewhere (in one particular case the base is for some basic database stuff that utilizes "DBIx::Class"-auto-generated code). I highly doubt that it's tied to "use base" at all, but instead is caused by modules that are highly dynamic (do things like create methods at runtime like DBIx::Class would do). But because this magic is buried in the base class you don't see it until you use that base class as your parent (via "use base"). Perl doesn't have a real way to unload a module or to completely force a reload. Apache::Reload tries it's best but there are lots of modules it can't handle. It's not it's fault really, it's a feature that's missing in Perl. These days, I never use Apache::Reload. I just restart my dev server ( yes, I believe each dev should have their own dev Apache server). -- Michael Peters Plus Three, LP
Re: [ANNOUNCE] mod_perl 2.0.5
[sNip] > > I find that running ModPerl on Windows generally works well until > > Perl scripts are changed frequently (and using the Reload module), > > and then Apache HTTPd will either stop responding or just crash out > > (especially if PerlMagick is in the mix). I wonder if this might be > > an OS-specific problem thought since my Unix servers just don't > > exhibit these symptoms. > > I use reload all the time it worked OK for most modules but some modules > (at least the ones that use "use base 'modulename';" ) will have problems. That's very interesting because where I'm seeing the crashing usually involves code that uses "use base" somewhere (in one particular case the base is for some basic database stuff that utilizes "DBIx::Class"-auto-generated code). The only other times I can recall where I've experienced this crashing is with the Apache2::Upload module, or with the Image::Magick (PerlMagick) module (there are only a few instances where I'm not using these two together). Even for test scripts where I don't use "use base" at all, I can still get crashing with Apache2::Reload after many script file changes, so I wonder if Apache2::Upload depends on something that uses "use base" somewhere, or if there's something common that it depends on that "use base" also depends on? If so, then perhaps this points to the problem. I know that Image::Magick is a problem child in many ways, so I suspect this could just be the same symptom with a different cause. > The good thing is that on Windows 7-64bit and 2008R2-64bit, the start and > stop of apache is much faster then on the old 32 bit systems (Win2003, XP) I find that 64-bit Windows 7 is faster at this too. Additionally, Windows 7 (and I recall also Vista) has a new "Delayed start" option for the Services which is nice for starting Apache HTTPd later on test boxen. Randolf Richardson - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada http://www.inter-corporate.com
Re: [ANNOUNCE] mod_perl 2.0.5
> Has anyone tried 2.0.5 on Windows? Yes I have compiled it with VC2010 and Activestate Perl 5.10.1 Build 1007. It works fine I have worked with it for a couple of days now. I have tested with Windows XP, Windows 7 and Windows 2003 all working fine. > I find that running ModPerl on Windows generally works well until > Perl scripts are changed frequently (and using the Reload module), > and then Apache HTTPd will either stop responding or just crash out > (especially if PerlMagick is in the mix). I wonder if this might be > an OS-specific problem thought since my Unix servers just don't > exhibit these symptoms. I use reload all the time it worked OK for most modules but some modules (at least the ones that use "use base 'modulename';" ) will have problems. The good thing is that on Windows 7-64bit and 2008R2-64bit, the start and stop of apache is much faster then on the old 32 bit systems (Win2003, XP) --- Thomas den Braber
Re: [ANNOUNCE] mod_perl 2.0.5
* Randolf Richardson wrote: > Date: Wed, 09 Feb 2011 19:22:06 -0800 > From: Randolf Richardson > To: mod_perl Dev , > mod_perl list > Subject: Re: [ANNOUNCE] mod_perl 2.0.5 > X-mailer: Pegasus Mail for Windows (4.52) > > > Awesome everyone. Thanks for working on the new release of mod_perl. I look > > forward to implementing it. > > This is great news! I'm very pleased to see this update because it > flies in the face of those who incorrectly insist that ModPerl is > dead because it hasn't been updated for a long time -- I've been > pointing out that the lack of updates are due to better quality code > and fewer change requirements. > > Thanks too all developers and contributors of ModPerl! I've been > hooked on this technology ever since I started using it, and I enjoy > the high performance and deep integration into APR and HTTPd. I totally agree! The quality design and code by Doug MacEachern laid the foundation. And thanks to Stas Bekman for the 2.0! -Jie
Re: [ANNOUNCE] mod_perl 2.0.5
> Awesome everyone. Thanks for working on the new release of mod_perl. I look > forward to implementing it. This is great news! I'm very pleased to see this update because it flies in the face of those who incorrectly insist that ModPerl is dead because it hasn't been updated for a long time -- I've been pointing out that the lack of updates are due to better quality code and fewer change requirements. Thanks too all developers and contributors of ModPerl! I've been hooked on this technology ever since I started using it, and I enjoy the high performance and deep integration into APR and HTTPd. > Has anyone tried 2.0.5 on Windows? I haven't yet, but I look forward to trying it on NetBSD 5.1. I am interested in trying it on Windows when a binary is available... I find that running ModPerl on Windows generally works well until Perl scripts are changed frequently (and using the Reload module), and then Apache HTTPd will either stop responding or just crash out (especially if PerlMagick is in the mix). I wonder if this might be an OS-specific problem thought since my Unix servers just don't exhibit these symptoms. [End of reply.] > On Wed, Feb 9, 2011 at 6:12 PM, Jie wrote: > > > Thank you so much for the new release! > > > > Jie > > > > Please think of our environment and only print this e-mail if necessary. > > > > * Andr? Warnier wrote: > > > > > Date: Tue, 08 Feb 2011 09:18:33 +0100 > > > From: Andr? Warnier > > > To: mod_perl Dev > > > CC: mod_perl list > > > Subject: Re: [ANNOUNCE] mod_perl 2.0.5 > > > User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) > > > > > > Many thanks guys, for keeping mod_perl alive and well (and perl too for > > that matter). > > > It is really a pity that not more people know how much their nice > > > web applications depend on it. > > > But then, maybe we should think that the people who matter, do know. > > > > > > Randolf Richardson - rand...@inter-corporate.com Inter-Corporate Computer & Network Services, Inc. Vancouver, British Columbia, Canada http://www.inter-corporate.com
Re: [ANNOUNCE] mod_perl 2.0.5
Awesome everyone. Thanks for working on the new release of mod_perl. I look forward to implementing it. Has anyone tried 2.0.5 on Windows? On Wed, Feb 9, 2011 at 6:12 PM, Jie wrote: > Thank you so much for the new release! > > Jie > > Please think of our environment and only print this e-mail if necessary. > > * Andr? Warnier wrote: > > > Date: Tue, 08 Feb 2011 09:18:33 +0100 > > From: Andr? Warnier > > To: mod_perl Dev > > CC: mod_perl list > > Subject: Re: [ANNOUNCE] mod_perl 2.0.5 > > User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) > > > > Many thanks guys, for keeping mod_perl alive and well (and perl too for > that matter). > > It is really a pity that not more people know how much their nice > > web applications depend on it. > > But then, maybe we should think that the people who matter, do know. > > >
Re: [ANNOUNCE] mod_perl 2.0.5
Thank you so much for the new release! Jie Please think of our environment and only print this e-mail if necessary. * Andr? Warnier wrote: > Date: Tue, 08 Feb 2011 09:18:33 +0100 > From: Andr? Warnier > To: mod_perl Dev > CC: mod_perl list > Subject: Re: [ANNOUNCE] mod_perl 2.0.5 > User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) > > Many thanks guys, for keeping mod_perl alive and well (and perl too for that > matter). > It is really a pity that not more people know how much their nice > web applications depend on it. > But then, maybe we should think that the people who matter, do know. >
Re: [ANNOUNCE] mod_perl 2.0.5
On Tue, Feb 8, 2011 at 4:10 AM, Clinton Gormley wrote: > On Mon, 2011-02-07 at 17:55 -0800, Fred Moyer wrote: >> mod_perl 2.0.5 is here! > > Well done! and thanks Thanks to the users who took the time to try out release candidates, fix and report bugs. Saw this today - word is getting out about the release: http://techfeed.ru/2011/02/vyshel-modperl-2-0-5/
Re: [ANNOUNCE] mod_perl 2.0.5
On Mon, 2011-02-07 at 17:55 -0800, Fred Moyer wrote: > mod_perl 2.0.5 is here! Well done! and thanks clint
Re: [ANNOUNCE] mod_perl 2.0.5
Many thanks guys, for keeping mod_perl alive and well (and perl too for that matter). It is really a pity that not more people know how much their nice web applications depend on it. But then, maybe we should think that the people who matter, do know.
[ANNOUNCE] mod_perl 2.0.5
mod_perl 2.0.5 is here! Thanks to the many, many contributors to this version. Please see the summary of changes below, along with a special dedication for this release to Randy Kobes. You can get mod_perl 2.0.5 at one of the following urls, including the CPAN: http://perl.apache.org/download/index.html http://apache.org/dist/perl/mod_perl-2.0.5.tar.gz http://apache.org/dist/perl/mod_perl-2.0.5.tar.gz.asc (pgp sig) md5: 03d01d135a122bd8cebd0cd5b185d674 --- The mod_perl PMC dedicates this release of mod_perl to Randy Kobes, who passed away in September 2010. Randy was a member of the mod_perl project management committee and a co-author of the mod_perl Developer's Cookbook. His work helped many Windows mod_perl users. His work with ppm files, and Win32 perl users will be sorely missed. He was kind, bright, and always willing to lend a hand on the mod_perl user's list. Prepare modperl for the upcoming perl 5.14 [Torsten Foertsch] Add lib/ModPerl/MethodLookup.pm to MANIFEST via lib/ModPerl/Manifest.pm RT #48103 reported by mar...@cpan.org [Fred Moyer] PerlIOApache_write() now throws an APR::Error object, rather than just a string error, if modperl_wbucket_write() fails. [Steve Hay] Authentication tests fail with LWP 5.815 and later [Doug Schrag] Concise test won't perform unless StatusTerse is set to ON [Doug Schrag] Look for a usable apxs in $ENV{PATH} if all other options fail, then prompt the user for one. [Phred] Work around bootstrap warnings when Apache2::BuildConfig has not been created yet. [Phred] Remove Apache::test compatibility (part of mod_perl 1.2.7), that code causes build issues and is 4 versions out of date. [Phred] Make sure perl is built either with multiplicity and ithreads or without both [Theory, Torsten] Support for "install_vendor" and "install_site" make targets [Torsten] Run tests on bundled pure perl Apache::* modules [Gozer, Phred] Implement a mini-preprocess language for map-files in xs/maps. [Torsten Foertsch] Implement APR::Socket::fileno [Torsten Foertsch] Export PROXYREQ_RESPONSE, a missing PROXYREQ_* constant [Gozer] Make sure standard file descriptors are preserved by the perl-script handler [Torsten Foertsch] Fix the filter init handler attribute check in modperl_filter_resolve_init_handler() [Torsten Foertsch] Make sure buffer is a valid SV in modperl_filter_read() [Torsten Foertsch] Move modperl_response_finish() out of modperl_response_handler_run in mod_perl.c [Torsten Foertsch] "MODPERL_INC= now correctly supported as an argument to Makefile.PL" [Torsten Foertsch] Fix an XSS issue in Apache2::Status reported by Richard J. Brain . [Torsten Foertsch] Add NOTICE file to the distribution. [Joe Schaefer] Make sure Apache2::RequestIO::read doesn't clear the buffer on end of file and handle negative offsets and offsets that are larger than the current string length. [Torsten Foertsch] Fix a problem that could make APR::XSLoader and Apache2::XSLoader load the wrong shared library. [Torsten Foertsch] Fix compilation when using a non-threaded APR. [Gozer, Philip M. Gollucci] Make sure mod_perl's own ChildInitHandlers are run before user supplied ones. This fixes the incorrectly reported value of $$ at ChildInit time [Gozer]