Thankgs for all the help guys.
Through some digging, I found some new files that were calling "require
moduleX.methods", which seem to be the culprit.
Thanks again!
Perrin Harkins wrote:
>
> aj2taylo wrote:
>> Correct, moduleX.methods has sub routines defined, but is not itself a
>> packag
Alex Beamish wrote:
The current solution is that we generate high resolution page images for
the documents in question, and then resize them on the fly using mod_perl.
This solution works well locally, but the problem is that we also have a
satellite office, and the VPN between the offices is
aj2taylo wrote:
Correct, moduleX.methods has sub routines defined, but is not itself a
package. This is all part of a legacy system, and moduleX.pm is used as a
form handler, so moduleX.methods exists purely for architectural reasons
(separating certain functions from the form handling functions
On 12/13/06, Robert Landrum <[EMAIL PROTECTED]> wrote:
Alex Beamish wrote:
> I'll deal with multiple documents with some combination of stale timers
> and LRU slots, but that's not really what I see as the most complicated
> or difficult part of this problem. For this particular application, my
Alex Beamish wrote:
I'll deal with multiple documents with some combination of stale timers
and LRU slots, but that's not really what I see as the most complicated
or difficult part of this problem. For this particular application, my
inactivity timer will probably by 10-15 minutes, and I'll ex
>
>Sorry, one other thing I didn't mention from the start is that the errors are
>happening inconsistently. We can rarely duplicate the error, but see it
>showing up in log files, and a QA can periodically replicate it.
>
>So do you think it be related to a bad Apache process, rather than softwar
aj2taylo wrote:
Sorry, one other thing I didn't mention from the start is that the errors are
happening inconsistently. We can rarely duplicate the error, but see it
showing up in log files, and a QA can periodically replicate it.
So do you think it be related to a bad Apache process, rather th
Sorry, one other thing I didn't mention from the start is that the errors are
happening inconsistently. We can rarely duplicate the error, but see it
showing up in log files, and a QA can periodically replicate it.
So do you think it be related to a bad Apache process, rather than software
based
Thanks for the link, I'll investigate that further.
Correct, moduleX.methods has sub routines defined, but is not itself a
package. This is all part of a legacy system, and moduleX.pm is used as a
form handler, so moduleX.methods exists purely for architectural reasons
(separating certain functi
On 13/12/06, Malka Cymbalista <[EMAIL PROTECTED]> wrote:
I am running Apache 2.0.55 with mod_perl 2.0.1 and Perl 5.8.1 on a Sun
Solaris machine. We would like to do http authentication via our ldap server
so we need to install mod_auth_ldap.
The instrictions I found for installing mod_auth_ldap
On Wednesday 13 December 2006 02:03, Alex Beamish wrote:
> Interesting suggestions, thank you, and I'm coming around to the idea that
> a daemon will need to be used for the heavy lifting .. and then perhaps
> mod_perl can communicate with the daemon using named pipes ..
>
> The whole point of this
I am running Apache 2.0.55 with mod_perl 2.0.1 and Perl 5.8.1 on a Sun
Solaris machine. We would like to do http authentication via our ldap
server so we need to install mod_auth_ldap.
The instrictions I found for installing mod_auth_ldap
(http://www.muquit.com/muquit/software/mod_auth_ldap/mod_aut
12 matches
Mail list logo
