RE: Intermittent File Upload Failures - CGI tmpfile unlinked
An open file handle is a link; when creating a file with open you actually have
two links to the file - one for the directory's link to it, and one for the
process's link to it.
Therefore unlinking the file from the file system simply reduces its link count
to 1, and it will stay around, writable on disk but not in any directories,
until it is closed, at which time it will automatically disappear.
This is great for temporary files because you can take care of the extra
directory entry right up front, no cleanup special required beyond closing the
filehandle.
I don't believe that the problem you are having is that the file is unlinked
from the filesystem. That would not stop it from being writable. The problem
may be that the file is inappropriately closed later before its fseek'd back to
the beginning to operate on the temp contents, thus causing it to really
disappear.
David
-Original Message-
From: mjurgens [mailto:mjurg...@edcint.co.nz]
Sent: Tuesday, March 30, 2010 12:08 AM
To: modperl@perl.apache.org
Subject: Intermittent File Upload Failures - CGI tmpfile unlinked
I need some help trying to work out why CGI.pm (guessing at the module)
appears to unlink a temporary file just after opening it and before writing
some uploaded file content to it.
I use input type=file in a form which I POST to a modperl Apache server
(version 2.2.14) on Fedora 10.
Intermittently the perl script is unable to access the CGItemp file. Here's
what I have found:
A network/packet trace shows the correct transmission of the HTTP and file
each time.
A Data::Dumper of the CGI variable instance shows the form variable has been
set to a file handle like this
'config_file' = [
$VAR1-{'.tmpfiles'}{'*Fh::fh00013Smartmon_Initial_Config_Export.txt'}{'hndl'}
]
However when the program goes to access the temporary file eg
/usr/tmp/45632, it does not exist.
I started printing the httpd PID in the HTTP output and found that some of
the processes consistently failed and others would consistently work.
I ran an strace on each of the httpd processes (running with 5 children) and
found that the failing processes would unlink the CGItemp file just after
opening it - so this is why it is unavailable to the perl script later on. A
good processes would open the CGItemp file and then start writing to it.
GOOD PROCESS (strace output):
---
open(/usr/tmp/CGItemp45478, O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = 22
ioctl(22, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbfcc4e08) = -1 ENOTTY
(Inappropriate ioctl for device)
_llseek(22, 0, [0], SEEK_CUR) = 0
fstat64(22, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
fcntl64(22, F_SETFD, FD_CLOEXEC)= 0
write(22, [MonsvrConfig]\r\nmonsvr_protocol=..., 3464) = 3464
BAD PROCESS (strace output):
-
open(/usr/tmp/CGItemp45481, O_RDWR|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = 21
ioctl(21, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbfcc4e08) = -1 ENOTTY
(Inappropriate ioctl for device)
_llseek(21, 0, [0], SEEK_CUR) = 0
fstat64(21, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
fcntl64(21, F_SETFD, FD_CLOEXEC)= 0
unlink(/usr/tmp/CGItemp45481) = 0
Why does it get unlinked just after opening and before the uploaded content
can be written to it?
--
View this message in context:
http://old.nabble.com/Intermittent-File-Upload-Failures---CGI-tmpfile-unlinked-tp28078476p28078476.html
Sent from the mod_perl - General mailing list archive at Nabble.com.
RE: Intermittent File Upload Failures - CGI tmpfile unlinked
Let us say for the sake of example that this is the sequence during success: 1. create/open file 2. write to file 3. close file 4. reopen file 5. provide file handle 6. close file 7. unlink file Lets imagine that something went wrong with the apache server and it dropped the post/form data that otherwise would have been put in its temp file. The system sequence would look like this: 1. create/open file 3. close file 7. unlink file Hm, that sounds like your symptom. A close friend and business partner of mine was complaining about a problem he encountered in his apache server unexpectedly after years of problem free operation. His cgi scripts were randomly - and for certain clients consistently - not receiving their form posts. His error logs were spammed, his customers were quite annoyed. We spent some time speculating about what could cause such behavior, but in the end he went for the generally sane step of making sure he had the latest apache server software running on his servers. The problem disappeared. It occurs to me that the symptom you are troubleshooting is remarkably similar to the same problem. Perhaps there is a bug that has been fixed, and you need to update apache to a newer release? It is worth a try, and it does match the case study - though we have no idea why the server would suddenly have developed this form data delivery problem. Perhaps its one of those strange artifacts in complex systems that we work around and don't worry about overly much. David -Original Message- From: mjurgens [mailto:mjurg...@edcint.co.nz] Sent: Tuesday, March 30, 2010 2:41 PM To: modperl@perl.apache.org Subject: RE: Intermittent File Upload Failures - CGI tmpfile unlinked You'll need to be more precise than this because I can't quite follow your logic given that in a good process the strace shows the file being written to, but in a bad process it shows it being unlinked instead of being written to (and it is never written to, and the perl also can not find the file after being given the file name). Ihnen, David wrote: I don't believe that the problem you are having is that the file is unlinked from the filesystem. That would not stop it from being writable. The problem may be that the file is inappropriately closed later before its fseek'd back to the beginning to operate on the temp contents, thus causing it to really disappear. David -- View this message in context: http://old.nabble.com/Intermittent-File-Upload-Failures---CGI-tmpfile-unlinked-tp28078476p28088874.html Sent from the mod_perl - General mailing list archive at Nabble.com.
RE: Best way to pass arguments to an Apache2::SubProcess?
Environment variables have size limits - you should pass it as the args
reference because of that, and the fact that you're sending a pointer rather
than the whole data helps too, though the system is probably copying it
somewhere in there you shouldn't have to worry about it.
The point they're inferring in the examples is that the second element is a
list reference - not whether it's a referenced to a named list or not is
irrelevant.
David
-Original Message-
From: Tosh Cooey [mailto:t...@1200group.com]
Sent: Tuesday, February 02, 2010 5:06 PM
To: modperl@perl.apache.org
Subject: Best way to pass arguments to an Apache2::SubProcess?
So my will has crumbled, mostly because I'm probably not very good at
the resident in memory part of mod_perl and I will be using
Apache2::SubProcess to fire off a sub-process.
There seems to be two easy ways to send data to my detached sub-process;
via an \...@args or via $r-subprocess_env-set.
I would like to pass large data structures which I will JSON encode and
I'm wondering which of the above would be best for that, if any, and
what the limitations are of either.
Also, I was wondering, in the docs for Apache2::SubProcess in the
section about properly detaching the sub-process it has in the example:
$r-spawn_proc_prog ('/path/to/detach_script.pl', $args);
Is there a reason $args is used rather than \...@args as outlined earlier
in the docs?
opt arg2: \...@argv ( ARRAY ref )
Or is it possible to create an $args-[0..10] and pass that?
Thanks!
Tosh
--
McIntosh Cooey - Twelve Hundred Group LLC - http://www.1200group.com/
RE: Use form instead of AuthType Basic (pop-up windows)
I happen to have just finished debugging my latest authen/authz cookie-based authentication module last night, so this is *really* fresh in my head. So right now you're using AuthType basic. Change that to something else specific to your module. The basic auth will no longer respond. Program an authentication handler (point to with PerlAuthenHandler directive). It returns Apache2::Const::DECLINED if the -auth_type doesn't match your custom type. Authen handlers set the -user of the requestrec object (probably by reading and validating a cookie in this case). If authorization is required for the request and you didn't set a username, you should probably return Apache2::Const::FORBIDDEN. If it succeeded or it doesn't matter, you can return Apache2::Const::OK; Program an authorization handler. (point to with PerlAuthzHandler directive). This use the Apache2::Access::requires method to get a list of your authentication requirements from the auth config in apache's config file (like Require valid-user). And Apache2::Access::satisfies to determine how you interpret the list of requirements. If you want to use a straight login page, If Authorization fails, set error header 'Location' to the location of your login script and return Apache2::Const::REDIRECT from the handler. If you want to use an error document, If Authorization fails, return Apache2::Const::AUTH_REQUIRED or Apache2::Const::FORBIDDEN from the handler. (configure ErrorDocument 401 or 403 respectively) If authorization succeeds, simply return Apache2::Const::OK. I also have handlers functions for LOGIN and LOGOUT which set and clear the auth cookie. That's different though - Authen/Authz is the part where you decide if the user is recognized and is allowed to access, which is what you asked about. David From: Juan Manuel Parrilla Gutiérrez [mailto:joanma...@gmail.com] Sent: Thursday, January 21, 2010 9:26 AM To: mod_perl list Subject: Re: Use form instead of AuthType Basic (pop-up windows) Hello, I am sorry if I didnt explain me properly. What I want to know is understand how use a formulary instead of AuthType Basic. I know there are several modules that are doing this, but it is not about using one, it is about understanding how. I am doing my own Auth module (just to learn about it and mod_perl) and I would like to use a form instead of pop up window, and using CGI is not an option because I want to use Authz and Authen handlers. What I need are the basic steps to move from AuthType Basic to use a form. Thank you very much for all your answers, Juan Manuel Parrilla Gutierrez 2010/1/21 André Warnier a...@ice-sa.commailto:a...@ice-sa.com Juan Manuel Parrilla Gutiérrez wrote: Hello, this is my first message to this list and I am also a bit new to mod_perl. My question is simple, in all the documentation I have found about mod_perl and auth (like practical mod perl, or writing apache modules in perl and c) they are always using AuthType Basic, so when the users tries to acess some protected content, a pop up windows will appear to ask for name/pass. What I want to do is to use a formulary instead of that pop-up window. As far as I know looking at AuthCookie, for example, there they define AuthType Sample::AuthCookie and they also define a login.plhttp://login.pl and different configs in the conf files. I want to know the different steps to define and use a form instead of AuthType Basic. Have a look here : http://cpan.uwinnipeg.ca/htdocs/Apache-AuthCookie/Apache2/AuthCookie.html and scroll to the section THE LOGIN SCRIPT If you install that module, it comes along with examples. AAA is tricky, and maybe not the easiest way to start playing with mod_perl. But this documentation is well-done, and should get you started, if you follow it carefully.
RE: Use form instead of AuthType Basic (pop-up windows)
I suppose it is not obvious that when using login page authentication that you are responsible for the creation of the mechanism by which you identify the user? I could point out that merely the fact you are utilizing a login form does not mean you HAVE to use cookies - it just has less ramifications than other possibilities. That is, whether the request is GET /index.html HTTP/1.1 Host: myserver.com Cookie: AuthTicket=username-ABCDEFGHIJKLM Or the request is GET /username-ABCDEFGHIJKLM/index.html HTTP/1.1 Host: myserver.com Your authorization handler can get the string 'username-ABCDEFGHIJKLM' and use it for the purposes of authentication/authorization. Just in the latter case, you'll be adding a PerlMapToStorageHandler to map around the extra auth information in the url and still access the file! (I've used this strategy of embedding auth tickets in urls for download and media links handled by external programs that won't have the cookie) David From: Juan Manuel Parrilla Gutiérrez [mailto:joanma...@gmail.com] Sent: Thursday, January 21, 2010 10:21 AM To: Ihnen, David Cc: mod_perl list Subject: Re: Use form instead of AuthType Basic (pop-up windows) Thank you for the information. I didnt know that what login and logout scripts were doing was setting/clearing the cookie. Juan Manuel Parrilla El 21 de enero de 2010 19:15, Ihnen, David dih...@amazon.commailto:dih...@amazon.com escribió: I happen to have just finished debugging my latest authen/authz cookie-based authentication module last night, so this is *really* fresh in my head. So right now you're using AuthType basic. Change that to something else specific to your module. The basic auth will no longer respond. Program an authentication handler (point to with PerlAuthenHandler directive). It returns Apache2::Const::DECLINED if the -auth_type doesn't match your custom type. Authen handlers set the -user of the requestrec object (probably by reading and validating a cookie in this case). If authorization is required for the request and you didn't set a username, you should probably return Apache2::Const::FORBIDDEN. If it succeeded or it doesn't matter, you can return Apache2::Const::OK; Program an authorization handler. (point to with PerlAuthzHandler directive). This use the Apache2::Access::requires method to get a list of your authentication requirements from the auth config in apache's config file (like Require valid-user). And Apache2::Access::satisfies to determine how you interpret the list of requirements. If you want to use a straight login page, If Authorization fails, set error header 'Location' to the location of your login script and return Apache2::Const::REDIRECT from the handler. If you want to use an error document, If Authorization fails, return Apache2::Const::AUTH_REQUIRED or Apache2::Const::FORBIDDEN from the handler. (configure ErrorDocument 401 or 403 respectively) If authorization succeeds, simply return Apache2::Const::OK. I also have handlers functions for LOGIN and LOGOUT which set and clear the auth cookie. That's different though - Authen/Authz is the part where you decide if the user is recognized and is allowed to access, which is what you asked about. David From: Juan Manuel Parrilla Gutiérrez [mailto:joanma...@gmail.commailto:joanma...@gmail.com] Sent: Thursday, January 21, 2010 9:26 AM To: mod_perl list Subject: Re: Use form instead of AuthType Basic (pop-up windows) Hello, I am sorry if I didnt explain me properly. What I want to know is understand how use a formulary instead of AuthType Basic. I know there are several modules that are doing this, but it is not about using one, it is about understanding how. I am doing my own Auth module (just to learn about it and mod_perl) and I would like to use a form instead of pop up window, and using CGI is not an option because I want to use Authz and Authen handlers. What I need are the basic steps to move from AuthType Basic to use a form. Thank you very much for all your answers, Juan Manuel Parrilla Gutierrez 2010/1/21 André Warnier a...@ice-sa.commailto:a...@ice-sa.com Juan Manuel Parrilla Gutiérrez wrote: Hello, this is my first message to this list and I am also a bit new to mod_perl. My question is simple, in all the documentation I have found about mod_perl and auth (like practical mod perl, or writing apache modules in perl and c) they are always using AuthType Basic, so when the users tries to acess some protected content, a pop up windows will appear to ask for name/pass. What I want to do is to use a formulary instead of that pop-up window. As far as I know looking at AuthCookie, for example, there they define AuthType Sample::AuthCookie and they also define a login.plhttp://login.pl and different configs in the conf files. I want to know the different steps to define and use a form instead of AuthType Basic. Have a look here : http://cpan.uwinnipeg.ca/htdocs/Apache-AuthCookie/Apache2
RE: $r-subprocess_env('REQUEST_URI') returns undef ?
At the risk of being kind of obvious, did you try $r-uri?
http://perl.apache.org/docs/2.0/api/Apache2/RequestRec.html#C_uri_
David
-Original Message-
From: Tosh Cooey [mailto:t...@1200group.com]
Sent: Friday, January 15, 2010 10:42 AM
To: modperl@perl.apache.org
Subject: $r-subprocess_env('REQUEST_URI') returns undef ?
From:
http://perl.apache.org/docs/2.0/api/Apache2/RequestRec.html#C_subprocess_env_
subprocess_env
Get/set the Apache subprocess_env table, or optionally set the value of
a named entry.
When the $key argument (string) is passed, it returns the corresponding
value (if such exists, or undef. The following two lines are equivalent:
$val = $r-subprocess_env($key);
$val = $r-subprocess_env-get($key);
Ok... Seems simple enough...
In my module if I do the following:
$r-subprocess_env;
my $uri = $ENV{REQUEST_URI};
The I get the URI.
But if I change the above to:
my $uri = $r-subprocess_env('REQUEST_URI');
I get undef.
Confused.
Tosh
--
McIntosh Cooey - Twelve Hundred Group LLC - http://www.1200group.com/
RE: FreeBSD 7.2, mod_perl2 Apache2::Cookie (libapreq2)
I have helped configure apache2 on versions of BSD - whether it's the latest or not is not in my knowledge, as I was merely handed servers of relative newness and paid to make apache2/mod_perl run on them. I just compiled from source with the packages in the BSD package system, configured them, and went on with life. Which isn't much help, since I don't know if it's the version you're talking about or if I somehow dodged whatever problem or method you're using to get binaries. David -Original Message- From: Joe Niederberger [mailto:jniederber...@comcast.net] Sent: Thursday, October 29, 2009 9:03 AM To: Joe Niederberger; mod_perl list Subject: Re: FreeBSD 7.2, mod_perl2 Apache2::Cookie (libapreq2) Should I conclude nobody is running mod_perl2 on the latest version of FreeBSD? - Original Message - From: Joe Niederberger jniederber...@comcast.net To: mod_perl list modperl@perl.apache.org Sent: Tuesday, October 27, 2009 10:04 PM Subject: FreeBSD 7.2, mod_perl2 Apache2::Cookie (libapreq2) Hello, Does anyone have the combination of FreeBSD 7.2, Apache2.2, mod_perl2 and libapreq2 all installed and working fine? My web-hoster is having exterme difficulties getting this set up. The Apache2.so is rife with undefined symbols that they cannot resolve. Simply making a call to the cookie jar and the process segfaults. Any help most appreciated. Thanks in advance. Joe Niederberger
RE: Why people not using mod_perl
My first response is, “What makes you think they don’t?” But I must point out that at the scale that Amazon runs at, the technology used for front end web page rendering – as critical as it is – not what runs Amazon. Can you run service calls to caches and systems from a mason-based mod_perl interface? Load Amazon.com to find out. Does that mean its running on mod_perl? Debatable. There are so many systems that are loosely coupled – they respond to, accept data from, and otherwise interact with the web site end of the system – but they’re java and c++ as well as perl – and THOSE – in my opinion at least – are ‘what amazon runs on’. And when you’re talking about what amazon runs on - these ‘back end’ type systems (those which are not specifically involved in the rendering of a page for display via http) mod_perl is of course *not* what they use, because – even if they ARE written in perl – they don’t work in that particular paradigm. So is ‘what you run on’ defined by your web server page view controller software – or the software that actually runs the heart your business and processes? Hmm. Does Coca-Cola run on a factory, or on a delivery truck? David From: Brad Van Sickle [mailto:bvs7...@gmail.com] Sent: Wednesday, September 16, 2009 3:32 PM To: mod_perl list Subject: Re: Why people not using mod_perl But I'm very interested to know at what point (if any) a site/app grows too large or too complex for mod_perl and what defines that turning point. Could Amazon run on mod_perl for example?
RE: Ways to scale a mod_perl site
It amounts to shared private key security.
Each web server, for instance, is configured with the key abcd1234
The session looks like
{ username = 'dog'
, group = 'canid'
, premium = 0
, login_time = 1253289574
}
I serialize that into a string with join '|', (map { $_, $session-{$_} } sort
keys %session;
$cookiebase = login_time|1253289574|group|canid|premium|0|username|dog
I apply md5_hex from the Digest::MD5 module
$signature = md5_hex($cookiebase . | . 'abcd1234');
Which yields
68b07c585c18282ea418937266b031d7
I then construct my cookie.
$cookie = join ':', %session, $signature;
So the cookie string looks like
premium:0:time:1253289574:username:dog:group:canid:68b07c585c18282ea418937266b031d7
When I receive the cookie on a request I just do the inverse.
my (%cookie, $signature) = split /:/, $cookie;
die 'BOGUS SESSION' unless ($signature eq md5_hex(join '|', (map { $_,
$session-{$_} } sort keys %cookie), 'abcd1234';
If you change the 'plaintext' string in any way - the md5_hex will change. If
you change or drop the signature, the md5_hex will change.
Its security through obscurity admittedly - security in that you can't see my
code, methodology, or shared secret configuration.
But most people consider that plenty secure for securing the session data.
David
-Original Message-
From: Brad Van Sickle [mailto:bvansick...@gmail.com]
Sent: Wednesday, September 16, 2009 9:13 AM
To: Michael Peters
Cc: Mod_Perl
Subject: Re: Ways to scale a mod_perl site
3) Being enabled by item 2, add more webservers and balancers
4) Create a separate database for cookie data (Apache::Session objects)
??? -- not sure if good idea --
I've never seen the need to do that. In fact, I would suggest you drop
sessions altogether if you can. If you need any per-session
information then put it in a cookie. If you need this information to
be tamper-proof then you can create a hash of the cookie's data that
you store as part of the cookie. If you can reduce the # of times that
each request needs to actually hit the database you'll have big wins.
Can I get you to explain this a little more? I don't see how this could
be used for truly secure sites because I don't quite understand how
storing a hash in a plain text cookie would be secure.
The thing I hate most about my secure applications is the fact that I
have to read the DB at the start of every request to ensure that the
session cookie is valid and to extract information about the user from
the session table using the session ID stored in the cookie. Hitting
the DB is the quickest way to kill performance and scalability in my
experience.I know a lot of true app servers (Websphere, etc..)
store this data in cached memory, but I was unaware that there might be
an option for doing this without using a DB with mod_perl .
RE: Why people not using mod_perl
Rather than develop and contribute the community the ideas used in integrating (IDE-app server-version store-job management) for the perl environment… you stop using perl for that. This is *exactly* why people are not using mod_perl – perl lacks the investment given to these big projects that people ARE investing in with the java technology. There is nothing magical about java applied to this integration – perl could it it as well (or better, given lessons learned from the earlier take). Sorry if I sound a bit bitter, but this lack of investment in my favored technology frustrates me something fierce. You and your business/company may have the clout after 10 years of building large critical systems to have the resources to invest in actually DOING this, and you would rather move to java. (not that it’s the only reason to move to java, but it sounds like it’s the fallover difference) Sigh. David From: Steven Siebert [mailto:smsi...@gmail.com] Sent: Wednesday, September 16, 2009 8:15 PM To: Jeff Nokes Cc: Brad Van Sickle; mod_perl list Subject: Re: Why people not using mod_perl I would also add, in addition to the frameworks, the availability of tools such as Netbeans and Eclipse IDE's are unmatched in the perl domain. These IDE's provide many high-level conveniences for enterprise developers, most notably in the realm of SOA (such as graphical building of BPEL and CEP). After nearly 10 years building and maintaining a critical government system, we are sadly migrating away from mod_perl to a J2EE based solution due to the success and growth of our mod_perl-based system. mod_perl and MySQL has served as well when we were taking on medium-to-large loads...however, as we are growing to a distributed (multi-site, multi-node) system, with tie-ins to numerous internal and external business systems across the enterprise, with development partners working at distributed factories...tools such as Netbeans and it's tight integration with Glassfish, SVN, and Hudson make building at this level a lot more manageable. I found that mod_perl for large-scale web applications works great, and if necessary horizontal scaling is achievable to sustain even more load. However, when dealing with complex SOA architectures, and the management of business workflows...the framework support and tools to accomplish this just aren't there in perl. Add to this Jeff's comment on the availability of high caliber perl engineers...we are almost forced to make this decision. We will continue to use mod_perl for other uses, such as our custom SCM/ALM system we built over the years...but the main product is migrating. On Wed, Sep 16, 2009 at 10:47 PM, Jeff Nokes jeff_no...@yahoo.commailto:jeff_no...@yahoo.com wrote: Doesn't Amazon run mod_perl/Mason? BTW, I agree with most of your points (would debate #4,5). I may substitute the phrase More convenient for Easier in #3. I would also add ... #7) How many engineers are available to hire that know or want to work with said technology? I built a great platform at eBay on mod_perl/Mason that handled eBay-size traffic; we ran 6 eBay sites on it. Now it is used for specialty e-commerce solutions like worldofgood.ebay.comhttp://worldofgood.ebay.com, global.ebay.comhttp://global.ebay.com (cross-border trade), dealfinder.ebay.comhttp://dealfinder.ebay.com, etc. In fact, on the same hardware, the main eBay Java app would support ~6 threads per box; the mod_perl platform supported ~60 (prefork), significant CapEx and power savings (which adds up at a place like eBay). From: Brad Van Sickle bvs7...@gmail.commailto:bvs7...@gmail.com To: mod_perl list modperl@perl.apache.orgmailto:modperl@perl.apache.org Sent: Wednesday, September 16, 2009 3:31:30 PM Subject: Re: Why people not using mod_perl This is a mod_perl list, so I would expect to see Perl championed pretty heavily, but Java, .net and there ilk are undoubtedly *the* choice for large web applications. I'd like to get into some discussion as to why almost all *large* sites choose these languages. I don't have any experience developing a large application in Java, although I do have a lot of experience working on the operations side of a large web application that is Java based. The reasons I generally hear for choosing Java over mod_perl are: 1) Speed - I don't buy this at all 2) Maintainability - I think this makes sense. Perl can be pretty easy to maintain if you stick a good framework around it, but you have to seek out that framework and YOU are responsible for adhereing to it. All of that is inherent in Java. It also helps that Java has OO built in. 3) Easier to package and build/move code - In my experience this is true. 4) Advantages to be gained from running on an actually application server - Also valid 5) Compatible enterprise class middleware - Also true, Java plugs into more truly enterprise level suff than Perl does.
RE: Why people not using mod_perl
Perhaps it could in some portion be quantified as The ability to think about a program without the ide/language structure suggesting paths for you. The possibilities are infinite. I can imagine that would be a problem for many. David From: Igor Chudov [mailto:ichu...@gmail.com] Sent: Thursday, September 17, 2009 12:22 PM Cc: mod_perl list Subject: Re: Why people not using mod_perl Just to add a little bit. In my experience, perl programming requires a certain type of mind. I cannot define it very precisely, but not everyone can think in perl. Those who can, basically, have a huge advantage over those who cannot, but that naturally limits perl adoption somewhat. I think that more people can think in java than in perl. I would hope that as long as use of perl is substantial, it will remain a viable platform that I can enjoy and use to live and make money. I do not care if perl is very popular, or just popular, I will be happy as long as it is viable. Igor
