Query
I am having a requirement as follows : I need to execute/interpret the perl requests away from mod_perl. Like, could mod_perl delegate the execution/interpretation of perl scripts to some other process. In the end, mod_perl would be used just to accept requests from the Web Server, but processing will be done elsewhere and response will be routed back through mod_perl. - rsr. Namaste, R S Chandrasekhar [EMAIL PROTECTED] ISD : 091-080-2052427 Telnet : 847-2427 Phone : 2052427
Re: input filter
- Original Message -
From: Steves
To: [EMAIL PROTECTED]
Sent: Monday, January 06, 2003 7:10 PM
Subject: input filter
*Sorry if this has gotten sent twice*
Hello,
I'm having some trouble configuring an input filter.. I'm using Apache
2.0.43, mod_perl 1.99_08-dev and perl 5.8.0.
In httpd.conf, I just did this inside a
PerlInputFilterHandler myApache::Filters::filter_out
My code looks something like this:
package myApache::Filters;
#here I loaded different modules etc..
sub filter_in : FilterConnectionHandler{
my ($filter, $bb, $mode, $block, $readbytes) = @_
my $rv =$filter->next->get_brigade($bb, $mode, $block, $readbytes);
return $rv unless $rv = APR::SUCCESS;
print STDERR "INPUT FILTER\n";
my $c = $filter->c
}
This is pretty much just taken from the mod_perl filter documenation, so I'm
pretty sure the code is OK.
My problem is, first and most obviously, the text "INPUT FILTER" gets
printed to STDERR twice per connection.
I'm not sure wether this is normal or not..
Secondly, from the time I hit refresh in my browser to the time the content
appears takes approximately one minute.. the request
completes eventually, it just takes a very long time. As soon as I take the
filter handler out of httpd.conf it works perfectly
Anyone know if this is a configuration issue or what? Thanks a lot for any
insights
Steve
SORRY!
The httpd.con configuration was a typo! It's really ->
PerlInputFilterHandler myApache::Filters::filter_in
it IS configured correctly in my conf file, sorry about the confusion
Steve
Re: Question from a newbie regarding apache and mod_perl
On Mon, 6 Jan 2003, sireesha vudatha wrote: > Date: Mon, 6 Jan 2003 16:25:04 -0800 (PST) > From: sireesha vudatha <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Question from a newbie regarding apache and mod_perl > > > Hi all, > > I am a beginner and am doing a course project for which I want to > know if mod_perl is suitable for my problem at hand. > > My problem is: When a user types in a question, then my perl > program(or whatever) has to go to the database and return the answer > back to the user. If its not able to find the question in the > database, then it has to transfer the connection to a person who > will answer the question and the database has now got to be updated > with this new question and answer. > > (I had written a simple program using the DBI and DBD::Mysql for > just retrieving the answer from the database) > > I don't know if the rest of my problem can be solved using mod_perl... > > Can anyone give me some ideas or suggestions that would help me out... > > Thanking u all in anticipation.. > > Sireesha Sireesha, Nothing you descibe seems to require mod_perl. I think perhaps you are unclear on just what mod_perl is meant to do. A great many people just use mod_perl to speed up execution of their Perl scripts. More advanced users want to manipulate different parts of the Apache request cycle using Perl. It sounds like your task will be most easily accomplished by sticking with a standard CGI script. If you find the performance is not what you desire, then consider running it under Apache::Registry. ky
Question from a newbie regarding apache and mod_perl
Hi all, I am a beginner and am doing a course project for which I want to know if mod_perl is suitable for my problem at hand. My problem is: When a user types in a question, then my perl program(or whatever) has to go to the database and return the answer back to the user. If its not able to find the question in the database, then it has to transfer the connection to a person who will answer the question and the database has now got to be updated with this new question and answer. (I had written a simple program using the DBI and DBD::Mysql for just retrieving the answer from the database) I don't know if the rest of my problem can be solved using mod_perl... Can anyone give me some ideas or suggestions that would help me out... Thanking u all in anticipation.. Sireesha Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now
input filter
*Sorry if this has gotten sent
twice*
Hello, I'm having some trouble configuring an
input filter.. I'm using Apache2.0.43, mod_perl 1.99_08-dev and perl
5.8.0.In httpd.conf, I just did this inside a
PerlInputFilterHandler
myApache::Filters::filter_outMy code looks something like
this:package myApache::Filters;#here I loaded different modules
etc..sub filter_in : FilterConnectionHandler{ my
($filter, $bb, $mode, $block, $readbytes) = @_ my $rv
=$filter->next->get_brigade($bb, $mode, $block,
$readbytes); return $rv unless $rv =
APR::SUCCESS; print STDERR "INPUT
FILTER\n"; my $c =
$filter->c}
This is pretty much just taken from the mod_perl filter documenation,
so I'mpretty sure the code is OK.My problem is, first and
most obviously, the text "INPUT FILTER" getsprinted to STDERR twice per
connection.I'm not sure wether this is normal or not..Secondly, from
the time I hit refresh in my browser to the time the contentappears takes
approximately one minute.. the requestcompletes eventually, it just takes a
very long time. As soon as I take thefilter handler out of httpd.conf it
works perfectlyAnyone know if this is a configuration issue or what?
Thanks a lot for
anyinsightsSteve
ANNOUNCE: Bricolage 1.4.6
The Bricolage team is pleased to announce the release of Bricolage 1.4.6, the Apache/mod_perl enterprise content management system. This maintenance release, which will likely be the final 1.4.x release, fixes over 20 bugs in version 1.4.5 Among the more important bug fixes are the following: * Bric::SAOP::Handler now properly logs fatal errors that are strings rather than exceptions. * Fixed bug in publish code that was attempting to use the Apache request object as a media asset. Thanks to John Greene for the spot. * Category permissions are now properly checked on assets when they're not in workflow as well as when they are in workflow. This means that if a group of users is granted permission to access stories in a category, they can now access those stories even if they're not in workflow. * The search interface for locating media and story assets to relate to a story now checks the permissions of the assets found and only displays the assets for which the user has at least READ permission. Thanks to Sean Greathouse for the spot. * Contributor Association now includes search options and only currently-associated contributors are displayed before searching. * The ability to select different fields by which to sort a list of objects now works again. [David] * Fixed reordering code for subelements. The select list for subelements should now always have an appropriate value. * Date fields can now be unset. That is, if each of the select fields is set to its label, rather than a value, it'll stay that way. This was first noticed with the "Expire Date" in stories. Thanks to Philip Fibiger for the spot. * Modified installation "CREATE DATABASE" command to always create the database with the encoding set to UTF-8 (UNICODE). [David] All users of earlier versions of Bricolage are encouraged to upgrade. For a complete list of the changes, see the changes file at https://sourceforge.net/project/shownotes.php?release_id=132033. ABOUT BRICOLAGE Bricolage, hailed as "Most Impressive" in 2002 by eWeek, is a full-featured, enterprise-class content management and publishing system. It offers a browser-based interface for ease-of use, a full-fledged templating system with complete HTML::Mason support for flexibility, and many other features. It operates in an Apache/mod_perl environment, and uses the PostgreSQL RDBMS for its repository. Learn more about Bricolage and download it from the Bricolage home page, http://bricolage.cc/. Enjoy! --The Bricolage Team
Re: mod_perl invokation valid?
Charlie Smith wrote: Question: Even though I have PERL 5.8 installed, we wish to get mod_perl installed to make use of caching. Currently, a listing of the %ENV hash indicates that we're running mod_perl/1.25. Okay, so you have mod_perl installed and now you want to use it. Take a look at the documentation for the Apache::Registry module that comes with mod_perl. That will help you run your CGI scripts under mod_perl. - Perrin
Re: Apache::DBI
Paul Simon wrote: I wasn't sure if Apache::DBI was screwing with ORACLE, especially with persistent connections... The Apache::DBI code is really short and easy to read. Basically, it just doesn't close connections when you call disconnect. It also does automatic rollbacks at the end of each request to make sure nothing is left in a bad state, and it pings the db connection each time you ask for one to make sure it's still alive. There's nothing in there that should interfere with the normal workings of DBI. - Perrin
Re: mod_perl invokation valid?
Hi there, On Mon, 6 Jan 2003, Charlie Smith wrote: [snip,snip] > assume we'll see a speed up after upgrading mod_perl? Your question is not clear. It depends on what you're doing with it. If you're already using mod_perl then simply upgrading it won't give you a substantial performance improvement. Read the mod_perl Guide, you'll find it at the mod_perl home page http://perl.apache.org and it tells you a lot about performance tuning and other useful stuff. > My configuration includes: > GCC 2.95, PERL 5.8, DBI 1.3 and DBD::Oracle 1.12, Oracle 9.0.1SunOS 5.8 Generic > 108528-12 sun4u sparc SUNW, Ultra-80, Apache 1.3.19 mod_perl/1.25 You should upgrade to the latest versions of Apache and mod_perl (versions 1.3.x and 1.2x, not mod_perl 1.99 which is really 2.0x:) There have been problems now and again with SunOS but don't let me worry you about that, it might not happen. 73, Ged.
mod_perl invokation valid?
I'm a newbee at this, so please have patience. Question: Even though I have PERL 5.8 installed, we wish to get mod_perl installed to make use of caching. Currently, a listing of the %ENV hash indicates that we're running mod_perl/1.25. PERL 5.8 is also listed out in the PERL5LIB env variable in httpd.conf. Is it correct assume we'll see a speed up after upgrading mod_perl?IF not, what else might need to be done to acheive a performance improvement with caching PERL. My configuration includes: GCC 2.95, PERL 5.8, DBI 1.3 and DBD::Oracle 1.12, Oracle 9.0.1 SunOS 5.8 Generic 108528-12 sun4u sparc SUNW, Ultra-80, Apache 1.3.19 mod_perl/1.25 Thanks, Charlie 1/6/02 -- This message may contain confidential information, and is intended only for the use of the individual(s) to whom it is addressed. ==
Re: Apache::DBI
--- Randy Kobes <[EMAIL PROTECTED]> wrote:
> On Thu, 2 Jan 2003, Paul Simon wrote:
>
> > Hi all
> >
> > I have a feeling this may be [OT], "take it to the
> DBI
> > list..." But I'm hoping to eliminate as much as
> > possible any suspicion that Apache::DBI/mod_perl
> is
> > causing my headache. I'm trying to push this
> platform
> > at work ;) If anyone can shed some light on this
> then
> > I'd be very appreciative, of course.
> >
> > I have what's becoming a reoccuring problem with
> an
> > app running under:
> >
> > Apache/2.0.42 (Win32) mod_perl/1.99_08-dev
> Perl/v5.8.0
> >
> >
> > I'm using Apache::compat and Apache::DBI for
> > persistent database connections.
> [ ... ]
> >
> > For completeness sake, here's the connection
> string:
> > my $DBH = DBI->connect("DBI:ODBC:$db", $user,
> $pass,
> > { RaiseError => 1, PrintError => 1, AutoCommit =>
> 1 })
> > or print( "Unable to connect to Database:
> > $DBI::errstr\n" ) ;
> >
> > Finally, the error message I'm getting is:
> >
> > DBI->connect(pdb9) failed:
> > [Oracle][ODBC][Ora]ORA-12535: TNS:operation timed
> out
> > (SQL-S1000)(DBD: db_login/SQLConnect err=-1) at
> > /Apache2/lib/perl/Apache/Standard3.pm line 29
> >
> > This problem goes away if the ORacle server(on
> it's
> > own hardware running windows 2000 pro) is
> restarted.
> > The last time this happened the box Oracle resides
> on
> > needed a cold reboot! So far, I haven't had to
> restart
> > apache.
> >
> > Could Apache::DBI or mod_perl2 cause this
> behavior?
>
> When you say the problem goes away, does this mean
> that
> things work fine after the restart of the Oracle
> server?
> Or do you periodically have to do this restart?
>
This problem has occured 2x so far. I was told by the
DBA that the ORACLE server is having hardware woes...
Anyway, the ORACLE server seems to be working fine,
again. I haven't had to restart the apache server
througout the trouble shooting process. I knew it had
something to do with ORACLE because the SQLplus client
wasn't connecting neither.
I wasn't sure if Apache::DBI was screwing with ORACLE,
especially with persistent connections...
> Are you using the latest versions of DBI and
> DBD::ODBC?
> If not, does an upgrade help?
Those modules are - whatever was bundled with your
first, warmly supplied :), Perl 5.8 + apache2 package
on theoryx5. Possibly, DBI => 1.30 and DBD::ODBC =>
0.43
I don't have quick access to the server, (I wish it
were on some kind of unix); so, i've been a little
lazy about checking the versions, for sure.
>
> --
> best regards,
> randy kobes
>
Thanks,
Paul
Re: mod_perl.c Not Compatible with Apache
Dale Lancaster wrote: Trying to narrow down a problem I am having with mod_perl::PerlRun on a stock RedHat 8.0 system, I have the following that simply doesn't work reliably under Apache 2.0.40 and mod_perl-1.99_05-3. The script runs fine for the first few refreshes and then I get the ominous error message: Error message: Not a CODE reference at /home/usa/cgi-bin/env.cgi line 7. Thanks for the report, Dale. Please try again with the current cvs, I've just committed a bug fix and a test that was reproducing it based on your report. __ 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
Re: [mp2.0] Input Filter virus scan (more info)
Issac Goldstand wrote: [snip] . Notice that you may need to have to store the context data between filter calls, which currently is not supported, but I'm working on adding this feature asap. If you need to store something in between the filter calls (filter may get the data in chunks, every time it's called it may only gets a chunk of data), the context is the way to store such data (e.g. partial bucket brigades, counters, etc.). Just give me some time and I'll commit the implementation and the updated doc with examples. I'm experiencing some problems with not seeing EOS, which prevents me from completing it. Stay tuned. __ 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
