Re: Sharing read/WRITE data between threads?
I've shared read-only data across threads many times a cheap and easy caching mechanims, but as I'm sure you've found in your research, the "copy-on-write" methodology employed by mod_perl prevents you from doing that for mutable data and I'm not aware of a way around that without fundamental changes to mod_perl itself. There are some very good reasons that mod_perl is architected that way. You may very well have a specific use case that makes sharing mutable data in memory for a threaded application desirable, but I know that oftentimes when I've tried to find ways to workaround a fundamental architectural element in a toolset, the best solution for me has ultimately been to rethink my approach rather than to wrestle the toolset into submission. In short, and although this isn't what you asked and I know next to nothing about your project, constraints or requirements... it sounds like you might want to consider a cache server (Redis/Varnish/Elasticache/etc...) and then solve the problem and proactively notify subscribed threads of changes if you need to. On 8/24/2021 7:50 PM, David Booth wrote: I am using Apache/2.4.41 (Ubuntu), with mod_perl. Apache uses multiple threads, and I want to share read/WRITE data between threads. (I.e., I want to be able to modify some shared data in one thread, such that other threads can see those changes.) In "Practical mod_perl" Stas Bekman describes how to share read-only data between threads, but says nothing about how to share WRITABLE data between threads. Any clues about how this can be done? I've searched high and low and found nothing. I will also want to know what mechanisms are available to coordinate access to that shared data, such as locks or semaphores. I also posted this message to StackOverflow, but got no response so far: https://stackoverflow.com/questions/68901260/how-to-share-read-write-data-in-mod-perl-apache2 Any help would be appreciated! Thanks, David Booth
Re: Trouble with script execution
Yep you need to restart to see your changes. Believe it or not, that's one of the *nice* things about mod_perl. Instead of compiling the code during each execution as PERL does when executed as a purely interpreted language , mod_perl causes each Apache child process to compile the code during it's first request/execution and then caches that compiled version of that code. You will need to restart the web server to clear that cache and force your changes to take effect. This is probably why you're getting inconsistent results after code changes, your seeing some requests that are handled by new child processes that are compiling the latest version of your code and some requests that are being handled by old child processes which are still serving previous versions that they've complied and cached. It may seem inconvenient for you, but this type of caching is a *necessity* when running PERL on any sort of real website that gets an appreciable amount of traffic for performance reasons. There are methods you can employ that tell Apache to automatically reload when it sees code change, pretty easy to find if you dig around the Internet.Although I wouldn't use this in a production system. On 5/18/2014 8:04 PM, Worik Stanton wrote: On 19/05/14 11:34, John Dunlap wrote: No, you have to restart the server for code changes to be noticed. Does that mean I have to restart my server for every change to a script? Worik
Re: Changing browser URL based on condition
Agree with the consensus. The URI should be descriptive of the
function, so any requests to /login should be from users who are
attempting to... login. The home page should be housed under a separate
URL (/home for example)
After the user has authenticated, the login module should redirect to
the /home URI. Any links to the home page from within the application
should likewise refer to /home. You should have security in place to
redirect any unauthenticated users to /login before requests for /home
(or any other part of your application) are processed.
If you for some reason simply MUST keep referring people to /login when
they are expecting to see the home page, put code in your login module
to check for authenticated users and redirect them to /home before
displaying the login page. If the user doesn't have a session, then go
ahead and display the login form.
On 11-07-11 03:14 PM, Jerry Pereira wrote:
Hi Edward,
I have the following design:
A single PerlResponseHandler for all requests. This handler based on
the path decides the action to be taken
For example, if the user submits to www.example.com/login
http://www.example.com/login, then the handler delegates the request
to authentication module, which will then either display the home page
(throug home page template) or login page again, based on the
success/failure of authentication mechanism. Since i am rendering the
page via template, i am able to generate the content of home page
which i then send back to the client, but the URL on the browser
remails the same (i.e. www.example.com/login
http://www.example.com/login), which is not true. Any suggestions to
handle this scenario will be great.
Thanks,
Jerry
On Mon, Jul 11, 2011 at 12:03 PM, Szekeres, Edward
edward.szeke...@perkinelmer.com
mailto:edward.szeke...@perkinelmer.com wrote:
If you are looking to do this for “cosmetic reasons”, I do this be
simply using frame sets and doing redirects in the child frame.
The URL displayed in the location bar will always be constant for
the parent frame. I don’t think there is any way to do this at
the core level or it would be a spoofers windfall. The browser
will always have the actual location in the info panel.
*From:*Jerry Pereira [mailto:online.je...@gmail.com
mailto:online.je...@gmail.com]
*Sent:* Monday, July 11, 2011 2:48 PM
*To:* modperl@perl.apache.org mailto:modperl@perl.apache.org
*Subject:* Changing browser URL based on condition
Hi All,
I would like to know if there is a way to change the URL displayed on
browser without using Redirect option. The URL visible on client
browser
must be based on some condition that is evaluated in my mod_perl
handler.
For example -
1. User types the URL - www.example.com http://www.example.com/,
this will display the login page.
2. Once the user enters the credentials and hits submit, the
request is
posted to www.example.com/login http://www.example.com/login action.
3. If the credentials entered by the user is valid then i would
like to show
the home page..uri
4. I am able to show the homw page, but the URL does not change to
www.example.com/home http://www.example.com/home, instead it
remains the same (i.e.
www.example.com/login http://www.example.com/login). I am using
Template toolkit to render my pages. I
tried $req-url('/home'), but that does not change the browser URI.
Any help will be appreciated.
Thanks,
Jerry
--
Your clothes may be the latest in style but you aint completely
dressed until you wear a smile!
Keep smiling : )
Re: mod_perl in larger scale environments
What are you guys using to cluster the LVS servers? Is that functionality native to LVS? Also, I've come across fastcgi a lot in researching this and I'm having trouble understanding exactly what it is. The fastcgi website makes it sound like it's almost a mod_perl replacement and another approach to executing perl code in a web environment, however a lot of the webservers that implement fastcgi keep referring to it almost like it's a protocol that proxy servers use to talk to their back end app servers... I'm a bit confused about what it is, what situations it's used in, and if it provides me any benefit if I'm already married to mod_perl. I know this probably isn't the best place to ask this question, but can someone clarify this for me? On 4/15/2010 8:04 PM, Cees Hek wrote: On Thu, Apr 15, 2010 at 4:38 PM, Cosimo Strepponecos...@streppone.it wrote: In data 15 aprile 2010 alle ore 05:11:15, Brad Van Sickle bvs7...@gmail.com ha scritto: LVS does sound interesting but in your infrastructure layout aren't your single LVS load balancers single points of failure? I simplified a bit too much :) Every LVS machine has a hot-spare, and you can perform manual or automated failover. Automated failover is said to keep your connections running while migrating them over to the backup lvs. We have never had a failure, just manual failover due to upgrades, etc... We use LVS to load balance our reverse proxies as well as our app servers. - 2 LVS servers using heartbeat for automatic failover (we are looking to switch to keepalived instead of heartbeat in the future), - 3 nginx servers which do content compression and ssl offloading as well as caching (we don't need 3 of them but we like the redundancy and the ability to drop one without impacting performance) - 5 app servers running apache and mod_perl We have just switched to nginx from squid in the last few months and have been very happy with it. nginx can also deliver static content directly or act as a FastCGI frontend (relaying the requests to backend app servers) as well as many other things. But our main reason for switching to nginx was the ability to offload SSL requests and remove that complexity from the app servers (we previously used squid as our reverse proxy which can't do SSL offloading). nginx can do it's own load balancing as well but we preferred to use our existing LVS infrastructure to handle that for us. As an added bonus, LVS also load balances our mail cluster... Cheers, Cees Hek
mod_perl in larger scale environments
Hello I have a lot of experience in large scale web applications using Java and Websphere, but I now find myself needing to scale a web application built on mod_perl, and I have some questions about best practices for doing that since I don't have any sort of deployment manager or an intelligent HTTP plugin. I currently have an application set up in the standard 3 tiered model: Apache web layer - Apache/mod_perl app layer - MySQL DB layer. Right now I have one app layer node, but traffic is dictating that I need to expand capacity there soon and I plan on adding more hosts to that layer. My first question relates to quality of service and load balancing: I'm currently using mod_proxy on the web layer, and I know I can set that up to load balance requests to multiple app layer nodes, but to the best of my knowledge mod_proxy is not able to provide any quality of service. So if a node in the app layer had a problem (or was shut down for maintenance) mod_proxy would be unaware of that and would still send requests to that node. How are situations like this normally handled? Is there something I can use other than mod_proxy that is intelligent enough to mark a host as down? I'd rather not use a hardware load balancer here if I can avoid it. My second question deals with management of multiple mod_perl nodes: At some point, if you have enough app layer nodes, managing the code deployments, apache configs and server restarts becomes very cumbersome if you're doing it all manually. Are there any tools that can make these tasks easier or give me one management view? Again, I'm used to working in web applications with a full blown app server. I love working with mod_perl, but I do find myself missing the advantages an app server gives me sometimes. Hopefully someone can offer me some suggestions here. Thanks
Re: mod_perl in larger scale environments
So it sounds like Apache is simply not going to meet my needs. In the event that I do need to replace Apache, hopefully you can save me some research time and recommend me one of the listed options that fulfills my needs (or confirm that perlbal does) I need the following features: 1) provides support for named virtual hosts 2) supports SSL to the client 3) supports URL rewriting (similar to mod_rewrite) 4) knows the availability of pool members and provides high availability. 5) the ability to serve static content itself I guess 5 isn't strictly neccessary, but it would be nice to serve static content (css/js/images/etc...) from the same piece of technology without proxying those requests to another Apache instance running on the same host (or something) Thanks for all the help! On 4/14/2010 5:48 PM, Perrin Harkins wrote: On Wed, Apr 14, 2010 at 5:33 PM, Brad Van Sicklebvs7...@gmail.com wrote: I didn't find much info on perlbal after a quick glance, I'll certainly give it a closer look, but my inital reaction is that I'm leary of replacing Apache on my web layer. I'm doing a few things with a few other modules ( mod_rewrite for example) in addition to mod_proxy, and from what I was able to find in my initial look, I didn't see any support for some of those types of things. There are many full-featured proxy servers these days. There's even mod_proxy_balancer for apache, but that doesn't do high-availability, which you're looking for. Check out some of these for reverse-proxying if you don't like perlbal: - nginx - lighttpd - varnish - pound All of those can serve as mod_perl frontends. - Perrin
Re: mod_perl in larger scale environments
LVS does sound interesting but in your infrastructure layout aren't your
single LVS load balancers single points of failure? Especially if they
are running on older hardware? Maybe that isn't important in your
environment? However, it seems like that negates a lot of the high
availability goal of load balancing.
It still may be a possibility for me, possibly running on the same
host as my existing web layer apache instance and using a localhost
connection... I will definitely look into it.
Again, I'm used to working in web applications with a full blown app
server. I love working with mod_perl, but I do find myself missing the
advantages an app server gives me sometimes.
I'm ignorant there. What advantages exactly?
I'l be brief here because this is a mod_perl list :)
The specific product I'm used to working with is IBM Websphere, which
allows you to cluster your individual app servers and then manage them
all from one administration tool. So settting or config changes, code
deployments, etc... are snynced across all nodes. It makes managing app
clusters extremely easy.It also provides a plugin to IBM's http
server that handles proxying back to the application servers and
provides load balancing/high availability,
Those are the two advantages that address my original questions
directly. App servers provide a lot of other benefits such as allowing
you to leverage things like shared memory and shared DB and messaging
connections/buses... many of these can be simulated in mod_perl.
(Apache::DBI, etc...)
On 4/14/2010 6:27 PM, Cosimo Streppone wrote:
In data 14 aprile 2010 alle ore 22:57:06, Brad Van Sickle
bvs7...@gmail.com ha scritto:
My first question relates to quality of service and load balancing:
Hi Brad,
we're using LVS (http://en.wikipedia.org/wiki/Linux_Virtual_Server),
and I find it very useful and reliable.
Our infrastructure for the modperl application, simplifying,
consists of:
a) 1 main front lvs load balancer
b) 2 web frontends
c) 1 back lvs load balancer
d) 12 apache/modperl backends
e) 5 db servers
f) ...other stuff... :)
a) load balances incoming traffic between the 2 web frontends.
b) rewrites backend requests to a single address, wlb (web load
balancer)
which is handled by c)
c) takes incoming requests for several different virtual hostnames,
as in:
wlb.domain.com = {weighted round robin to} =
(back1,back2,...,back12)
mlb.domain.com = {wrr} = (db1, db2, ..., db5) (mysql load balancer)
s-mlb.domain.com = {wrr} = (search-db1, search-db2, ...) (search
mysql lb)
d) app servers are stateless, so we don't need sticky sessions
This architecture can be simplified, and we're trying to do it.
So, I'm not saying this is the best practice or not even sane. :)
LVS performs health checking via HTTP requests,
with or without md5 checksum of the responses,
or direct TCP connections to the port you specify (f.ex. for db servers).
I'm currently using mod_proxy on the web layer, and I know I can set
that up to load balance requests to multiple app layer nodes, but to
the best of my knowledge mod_proxy is not able to provide any quality
of service. So if a node in the app layer had a problem (or was shut
down for maintenance) mod_proxy would be unaware of that and would
still send requests to that node.
That's where LVS is useful.
LVS can do direct routing or tcp handoff IIRC, and we're using it.
The client and servers talk directly to each other,
without taking up too much resources on the LVS machine itself.
I'd rather not use a hardware load balancer here if I can avoid it.
LVS usually runs on our older less powerful machines.
My second question deals with management of multiple mod_perl nodes:
At some point, if you have enough app layer nodes, managing the code
deployments, apache configs and server restarts becomes very
cumbersome if you're doing it all manually.
We're using a simple but limited in-house tool that basically uses
rsync, ssh, and keeps list of hosts w/ roles.
Currently for a pilot project I used puppet for config management
and fabric as last mile deployment tool. So far I'm happy
with the result.
Are there any tools that can make these tasks easier or give me one
management view?
I don't know. Everything we've done is command line based,
so it's not very friendly. Actually I'm currently looking into
higher level tools to integrate what we've done.
I also looked at ControlTier, but it feels too heavy for me.
Needs its own (powerful) machine. I'd be glad to hear experiences on it.
Again, I'm used to working in web applications with a full blown app
server. I love working with mod_perl, but I do find myself missing
the advantages an app server gives me sometimes.
I'm ignorant there. What advantages exactly?
Re: How to get a file listing
Apache knows the context, PERL does not.
Fully qualify that directory name and it should work.
On 2/20/2010 1:01 PM, ceauke wrote:
Hi there
Here is my code. I get the IMG displayed but also the perl error: No such
file or directory.
#!E:\ea12\apps\tech_st\10.1.2\perl\5.6.1\bin\MSWin32-x86\perl.exe
print Content-type: text/html \n\n;
print Test:;
print /Ski/temp.jpg ;
opendir(DIR, /Ski) or die print Error $!;
print Dir list: ;
while( ($filename = readdir(DIR))){
print($filename);
}
closedir DIR;
It seems like the webserver (apache) knows what /Ski is but perl doesn't.
It's looking for /ski in cgi-bin. my /ski folder is out of the root. I have
an alias, directory and location defined in httpd.conf for it. How do I get
perl to see it?
Re: Custom INC per-directory
I don't know the specifics of your project so it's quite possible that I'm missing something, but this all seems like an incredibly bad idea. Sure you can knock some cringe inducing code together and get it to technically work, but the very fact that you need to resort to these sort of unorthodox methods should be a hint that you might have something wrong in your systems or software design. Again, I lack a full perspective here and maybe you have good reasons, but this sounds like a problem screaming to be solved in conception, not in implementation. Adam Prime wrote: Alan Young wrote: Wouldn't using the Parent option ( http://perl.apache.org/docs/2.0/user/config/config.html#C_Parent_ ) work better for what you're trying to do? Parents requires vhosts, which he said he doesn't want to use. Adam
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: Updating cookies in header during request processing
All due respect, but hat's a little condescending... I generally cringe when I hear anyone advocating that there is one right way to do things that should be used in every instance In addition to Michael's points (which are totally valid) I would add that your solution is great for small/medium sized sites but as soon as you scale into sites with very large amounts of traffic it quickly raises a lot of operational concerns about where to store that data in place that's retrievable in a short enough time frame to not degrade performance. Solving that problem is going to cost time and money and will sometimes result in your application caring about session affinity, which is another operational concern. I'm not saying that these problems aren't solvable, I'm simply saying that I don't think it's nearly as cut and dried as you seem to, especially when you look at the app from and operational perspective. I can see both sides of this argument and I can see situations in in which either solution might be advantageous over the other. A lot depends on budget, environmental layout, how often the session is updated, how much data you're storing, etc... Perhaps you could outline in a little more detail why you think storing everything server side is the only right way to do things? Randal L. Schwartz wrote: Michael == Michael Peters mpet...@plusthree.com writes: Michael On 09/18/2009 10:33 AM, Randal L. Schwartz wrote: Ahh, phase 2 of cookie awareness. When you get to phase 3, you realize that cookies should really just be used to distinguish one browser from another, and hold everything server-side instead for far better security and flexibility. Michael I disagree. Using cookies for session data has a lot of advantages: [justifications snipped] Yes. Welcome to phase 2. Eventually, you'll enter phase 3. The smarter webdev people always do. I sounded exactly like you, once, and then grew out of it. The more you resist, the longer your delay. :)
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. (security frameworks, etc... ) 6) Support A lot of the industry seems look at Perl as obsolete technology that has been replaced by *insert hot new technology of the week here* which is a total shame. I've worked with a lot of technologies and I think Perl is a great choice for small/medium websites and webapps, which is probably what most of us work on. 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? Phil Carmody wrote: --- On Thu, 9/17/09, Igor Chudov ichu...@gmail.com wrote: My site algebra.com is about 80,000 lines of mod_perl code. I wrote a relatively large framework, with many homegrown perl modules, about five years ago. It uses a database, image generation modules, a big mathematical engine that I wrote (that shows work, unlike popular third party packages), etc. All pages of my site are dynamic and it is very image heavy due to math formulae. I can say two things: 1) It is relatively fast, serving pages in 0.1 seconds or so 2) Despite the quantity of code, and its age, it is still very maintainable and understandable (to me). In that case, would you like to fix its mangled output? e.g. http://www.algebra.com/algebra/homework/divisibility/Prime_factorization_algorithm.wikipedia   (Redirected from Prime factorization algorithm) faster than O((1+ε)b) for all positive ε an integer M with 1 ≤ M ≤ N Pollard's p − 1 algorithm Section 4.5.4: Factoring into Primes, pp. 379–417. Chapter 5: Exponential Factoring Algorithms, pp. 191–226. Chapter 6: Subexponential Factoring Algorithms, pp. 227–284. Section 7.4: Elliptic curve method, pp. 301–313. Eric W. Weisstein, “RSA-640 Factored†v • d • e AKS · APR · Ballie–PSW · ECPP · Fermat · Lucas · Lucas–Lehmer · Lucas–Lehmer–Riesel · Proth's theorem · Pépin's · Solovay–Strassen · Miller–Rabin · Trial division Sieve of Atkin · Sieve of Eratosthenes · Sieve of Sundaram · Wheel factorization CFRAC · Dixon's · ECM · Euler's · Pollard's rho · P − 1 · P + 1 · QS · GNFS · SNFS · rational sieve · Fermat's · Shanks' square forms · Trial division · Shor's Ancient Egyptian multiplication · Aryabhata · Binary GCD · Chakravala · Euclidean · Extended Euclidean · integer relation algorithm · integer square root · Modular exponentiation · Schoof's · Shanks-Tonelli Looks like you've got utf8 and iso8859-1 messed up. Phil
Re: FW: Apache::DBI Failed due to +GlobalRequest
I've run into this before. It's a bug in v1.07 of Apache::DBI
Open up the Apache/DBI.pm source file (on one of my test systems it's
installed in /usr/lib/perl5/site_perl/5.8.8/Apache/DBI.pm) aind the
following block of code:
/ if (!$Rollback{$Idx}) {
my $r;
if (MP2) {
$r = Apache2::RequestUtil-request;
}
elsif (Apache-can('push_handlers')) {
$r = 'Apache';
}
/
The problem with this is that if you're calling this from startup.pl
you're not actually in a request at that point (as someone already
mentioned) so without the eval there the script dies.
Fix it by wrapping the /$r = Apache2::RequestUtil-request;/ part in
an eval so it looks like this: /eval { $r = Apache2::RequestUtil-request;}
/
André Warnier wrote:
Kulasekaran, Raja wrote:
Hi,
Thanks for your mail. I did tried. It's not working .
Yes, I am sorry. I did not look close enough at the following error :
[Thu Sep 10 14:39:30 2009] [error] Global $r object is not available.
Set:\n\tPerlOptions +GlobalRequest\nin httpd.conf at
/var/www/audashboard/exec/startup.pl line 24.\nCompilation failed in
require at (eval 5) line 1.\n
In a mod_perl *request* handler, the first argument
(my $r = shift;)
is usually a pointer to the current Request object.
But in your startup script (startup.pl), that is not the case, because
when that script is run, there is no request yet.
I don't know what you are trying to do with $r in that startup script,
but something is wrong and maybe the error message above is misleading.
(I mean that it may have nothing to do with GlobalRequest at that stage.)
