[EMAIL PROTECTED]">After some further correspondance with Josh off the list I think I now know what was going on here.Steve Fosdick wrote:We have an application using Apache::ASP which worked fine when there
were just a few people using it but since user number have increased we
have started to get "Internal Server Error" return to clients in a few
odd cases and messages like:
[Sat Nov 24 20:48:34 2001] [error] [asp] [7228] [error] Undefined
subroutine
&Apache::ASP::Compiles::_home_indigo_releases_r2_2_app_global_asa::db_seqnext
called at (eval 132) line 27. <--> , /usr/share/perl5/Apache/ASP.pm line
1471
appearing in the error log. This is currently with Apache::ASP 2.21
(debian package - the ASP.pm appears to be version 2.07). I tried
Apache::ASP 2.27 and the problem was very much worse with that version
hence having reverted to 2.21. So..
1. Has anyone seen this before or know anything about what is going on.
Here's some guesses:
1) If you are using StatINC or StatINCMatch configs in production, this
could possibly contribute to this. Try not using these configs in production.
2) if you use the subroutine &db_seqnext() in your scripts, and its
defined in a script, and not in global.asa, this would be a problem.
Move the definition of &db_seqnext() to global.asa, which will act
as your perl library for your ASP application.
I was trying to build a site that had some modular code in it, i.e. perl modules that got 'use'd by the ASP pages and by other perl modules, but I wanted to support more than one version of both the ASP pages and the perl modules they depended on on the same machine, using virtual hosts.
>From this, I reasoned that if I left the perl modules to use the default namespace then when the module got compiled the names would be entered into a global.asa specific and therefore virtual host specific namespace and would therefore be separate from any similar named module in the other virtual host.
This worked in so far as the modules did get compiled into global.asa specfic name spaces, but it seems there is only one %INC array per perl interpreter and the key for this array is the module name and not the full path to the module name. The upshot of this is that once one version of a module had been compiled in one virtual host, when the other virtual host came to use the module it would consult %INC and conclude that the module was already compiled not knowing that the definition from the previous compilation was not available to it.
So, I don't see a way at the moment to do what I had originally set out to do. I can change the modules to each use its own namespace then the problem of not finding definitions would go away, but then so would any separation as both virtual hosts would then share the same copy of the module. Hopefully this will be solved when our second machine gets built.
Steve.
