I set this DEBUG in Apache::DBI module. Here is the debugging error it produces
at 'apachectl start':
2520 Apache::DBI skipping connection during server startup, read
the docu !!
2520 Apache::DBI skipping connection during server startup, read
the docu !!
2521 Apache::D
Jim,
Jim Schueler wrote:
With regards to Apache::DBI, it is very much supported :)
No. It is not. What little I know of you, you seem knowledgable and
experienced. But you don't seem to have read this thread. The
documentation says that the module will be supported by this list, and
the
> Modules with reliable owners, such as Soap::Lite, deserve the highest
> level of confidence.
Currently SOAP::Lite doesn't have an 'owner' per se. I sent a patch
into rt.cpan.org a few weeks ago, and as a result I was given COMAINT
on CPAN for it, applied many fixes, and released 0.716 (which con
Jim,
I just don't see the issue with not having an individual's name on one of
the mod_perl modules as the support contact. To me, Apache::DBI is being
supported, exactly as the documentation says. Someone wrote to the mailing
list, asked a question, and received responses that were trying to be
With regards to Apache::DBI, it is very much supported :)
No. It is not. What little I know of you, you seem knowledgable and
experienced. But you don't seem to have read this thread. The
documentation says that the module will be supported by this list, and the
facts now demonstrate othe
Jim Schueler wrote:
No apology please. In terms of trying to qualify any of this, a larger
statistical pool is better. And I am no authority. My perceptions are
largely based on forum postings which causes an inherent bias.
I'd love to see this conversation continue, especially if participa
> In their absence, I'd note that your post has an interesting ambiguity: Is
> the number of unsupported modules 2.5% or 25%?
The 'supported' metric doesn't really translate the same in reference
to open source software as it does to commercial software. When a
commercial software product becomes
No apology please. In terms of trying to qualify any of this, a larger
statistical pool is better. And I am no authority. My perceptions are
largely based on forum postings which causes an inherent bias.
I'd love to see this conversation continue, especially if participants
included those w
> the perl web dev world is more splintered and there are fewer people
> on the mod_perl list than there used to be. That's a little sad for
> me to see, but the new stuff is pretty nice too, and lots of people
> are still using mod_perl and answering questions on this list.
>
I wonder if the
Just butting in, apologies.
It may not have been Jim's intention below, but I get the impression that his comments on
CPAN are a bit harsh.
It is true that a number of modules are apparently no longer supported. I have used many
modules over the years, and sometimes have had problems with so
The mailing list has been the official place for support of all bundled
mod_perl modules for as long as I can remember. I don't think there's a
rule about perl core modules being passed between individuals either,
although I could be wrong. Sending people to a mailing list for support is
a common
I still use Alpine. And they never fixed the bug where ctrl-c (to cancel
a message) and ctrl-x (to send) are so easily confused. Oops. Maybe it's
time to start using a mouse.
Having wasted so much time, I'll try to be succinct:
Most modules on CPAN are bascially throwaways and not support
Hi Jim,
I appreciate the thought, but I'm not the mod_perl list. If you look at
who has done the most support around here recently, it's probably Torsten.
(Thanks Torsten!) More to the point, there are many people on the list
who know enough perl to help with a question about Apache::DBI. It's
There's an existing thread with an Apache::DBI question. But since I want
to post a separate question to this list, I decided to start a new thread.
Just got done reading the Man page for Apache::DBI. One of the last
notes suggests that this package is obsolete (having been replaced by
Class
Well, you are on the modperl list, so that means you. :)
Xinhuan, the error is harmless, but if you're concerned about it I would
try turning on debugging to make sure the connection is not being cached.
Do this:
$Apache::DBI::DEBUG = 2;
And then watch for a message like this in your log:
skippi
I'm afraid I'm out of my league. I just noticed the following comment on
the Apache::DBI man page:
Edmund Mergl was the original author of Apache::DBI. It is now supported
and maintained by the modperl mailinglist, see the mod_perl documentation
for instructions on how to subscribe.
-Ji
I believe I am using "my" declaration rather than "local". I also tried
explicitly disconnect but still have same issue. Since it only happens in
parent/child processes, I don't know a good way to debug parent/child, nor
reproducing the same error using a simple program. Can you guys help me
with t
Perrin is right. But fundamentally, I'd say that you're confusing
'local' and 'my' variable scoping:
http://www.perlmonks.org/?node_id=94007
-Jim
On Fri, 31 May 2013, Perrin Harkins wrote:
Try an explicit disconnect() call.
- Perrin
On Thu, May 30, 2013 at 7:46 PM, Xinhuan Zheng
wrot
Try an explicit disconnect() call.
- Perrin
On Thu, May 30, 2013 at 7:46 PM, Xinhuan Zheng wrote:
> The db handle is declared local and once it's out of scope, the destroy
> call will disconnect. But it appears even though variable is out of scope,
> we still get that error. Don't know why.
> -
Summary: Building 64 bit perl, mod_perl 64 bit apache and connecting to 64
bit MySql database on Solaris Sparc
We could successfully build 64 bit apache with the configuration options so
kindly shared by John D. Groenveld, also, in order to build mod_perl on 64
bit perl we had to recompile perl 64
20 matches
Mail list logo
