Each time LWP::UserAgent or LWP::Simple is used with mod_perl (PerlRun), Ubuntu 10.04.4 and Apache 2.2.14 I get about 50 or so error messages in the Apache error log:
Constant subroutine ModPerl::ROOT::ModPerl::PerlRun::home_user_public_html_index_2ecgi::RC_NOT_IMPLEMENTED redefined at /usr/lib/perl5/ModPerl/Util.pm line 69.
I have attempted defining the functions I will be using as:
use LWP::UserAgent qw(agent request);
However I am still getting these error messages. They are filling up the Apache error log very fast.
I think no warnings 'redefine'; will work.
use strict;
use warnings;
no warnings 'redefine';
Is how I usually do it.
Related
Got stuck on using Net::HTTP
when i create a Net::HTTP object it initialize with "IO::Socket::IP".
how can i change default socket without hard-coding? I would like to change it to IO::Socket::INET.
So if i hard-code socket, it works.
But when i'm trying to use Coro::LWP and Coro::LWP changes IO::Socket::INET to Coro::Socket i got error:
Status read failed: Transport endpoint is not connected at perl5/lib/perl5/Net/HTTP/Methods.pm line 282.
I need to change socket because Clickhouse module on cpan doesn't support async requests.
here is code that doesn't work
use IO::Socket::INET qw( );
BEGIN { $Net::HTTP::SOCKET_CLASS = 'IO::Socket::INET'; };
use Coro::LWP;
my $s = Net::HTTP->new(Host => "www.perl.com") || die $#;
$s->write_request(GET => "/");
print $_ for ( $s->read_response_headers );
fixed!
just change Coro::Socket with Coro::PatchSet::Socket
You can't use IO::Socket::INET or IO::Socket::IP with Coro. Coro is a co-operative multi-threading system, so it only works with co-operating modules, and neither of these modules are Coro-aware. (By "work", I mean allow threads and asynchronous operations to progress.)
Among other things, Coro::LWP specifically makes Net::HTTP use Coro::LWP::Socket instead of IO::Socket::INET. Your attempts to make Net::HTTP use IO::Socket::IP are counter-productive.
You said you're switching the module because Clickhouse (by which I presume you meant ClickHouse) doesn't support async requests, but replacing IO::Socket::INET with IO::Socket::IP doesn't help with that at all.
Have you looked at AnyEvent::ClickHouse?
I got a connection test script that is run on my client system and is calling a Perl DBI Proxy server via
my $dbh = DBI->connect("dbi:Proxy:$dbiproxy;dsn=$dsn", "$user","$pass",{ PrintError => 1}) || ($errmsg = "ERROR on connect");
When running the script it will fail stating
connect('hostname=***;port=2001;dsn=dbi:Oracle:***','***',...) failed: Cannot log in to DBI::ProxyServer: Unexpected EOF from server at /usr/local/share/perl/5.10.1/RPC/PlClient.pm line 79.
The log on the DBI Proxy server reads
Wed Dec 15 14:47:47 2015 err, Child died: Storable binary image v2.7 more recent than I am (v2.6) at blib/lib/Storable.pm (autosplit into blib/lib/auto/Storable/thaw.al) line 363, at /usr/lib/perl5/site_perl/5.8.0/RPC/PlServer/Comm.pm line 179
So I checked the Perl and Storable module version numbers of the two systems and the DBI proxy server seems to be rather outdated:
source: perl 5.10.1, storable 2.20, storable 2.7 (binary), Debian 6.0
target: perl 5.8.0 , storable 2.13, storable 2.6 (binary), RHEL 3
The problem is that I can not update the module/perl version of the target system, so I thought I could simply lower the utilized client version by modifying the /usr/local/share/perl/5.10.1/RPC/PlServer/Comm.pm file and change the line
require Storable;
to
use Storable 2.13;
but this will result in the same error as above. I also tried to use Storable 2.13 directly in my Perl test-script, but that does not change anything, either.
When googling this I could not find any solution, only confirmation that this version discrepancy can be a problem. Increasing the DBI_TRACE level on the client side also did not reveal anything new. Frankly I don't know what to try next and any help would be greatly appreciated.
Using MongoDB 2.4.5 with version 0.702 of the Perl MongoDB driver, I frequently run into exceptions like these:
recv timed out (30000 ms) at ...MongoDB/Cursor.pm line 161.
couldn't get response to throw out at ...MongoDB/Cursor.pm line 161.
missed the response we wanted, please try again at ...MongoDB/Cursor.pm line 161
invalid header received at ...MongoDB/Cursor.pm line 161.
can't get db response, not connected at ...MongoDB/Cursor.pm line 161.
The exceptions are intermittent, and often vanish on the next request (this is a web app). Occasionally, the exceptions will persist over several consecutive requests.
This is a tiny database running the default configuration (no sharding or anything fancy). I've tried using some of the tools listed here and here, but I'm unclear on how to apply them to this situation.
This is all running on Debian 7.1 64-bit. The web server is Mojolicious' hypnotoad 4.07 on perl 5.16.3 running behind apache2.
Can you kindly suggest some tools & strategies for diagnosing the problem? Thanks for your time.
From time to time I get the following warning in the logfile of my Wicket application:
04.10.2012 14:52:08,525 WARN [org.apache.wicket.core.request.mapper.AbstractBookmarkableMapper]
Unknown listener interface 'd allow_url_include=On '
What does that mean and how do I fix it? I tried Google, but I could only find results for the PHP configuration allow_url_include.
I'm using Wicket 6.0.0
Most likely an automated tool tries to exploit some PHP application. Wicket can't handle this request and prints the warning. Look in the access log what HTTP requests hit your server at this timestamp to see which request caused this warning.
It's safe to ignore this warning in this case.
I am getting this error in error_log one of my Perl CGI application. I am pretty sure I haven't changed my script at all and all of a sudden i have started getting this error.
This is what I see in error_log:
[Wed Jul 8 15:18:20 2009] [warn] FastCGI: server "/local/web/test/cgi-bin/test.pl" (pid 17033)
terminated by calling exit with status '255'
[Wed Jul 8 15:18:20 2009] [warn] FastCGI: server "/local/web/test/cgi-bin/test.pl"
has failed to remain running for 30 seconds given 3 attempts, its restart interval has been backed off to 600 seconds
(The snippet was edited for clarity)
Also, the AddHandler line for FastCGI exists in the config file.
Can any tell me the possible reasons for this error?
There is nothing recorded in Apache logs.
Here are two tips that might help (assuming your app is respecting the fastcgi protocol):
1. try to run the app in command line, this prove that you have execute bit and no compile errors in code.
2. check suexec.log of your apache server, this might show user/group or other errors related to your script.
You could try redirecting the STDERR from your Perl script, something like:
BEGIN { open STDERR, '>stderr.log' }
If your stderr.log file doesn't get created at all, it means that the script didn't even get executed, likely a suexec/permissions problem. Otherwise, you should have whatever went wrong with the Perl script in that file.