RE: Problem to execute sidecar Perl scripts when compiling POE::Component::Resolver 0.912 with PAR
Hi Rocco, thanks a lot (also for the refactoring improvement). Version 0.913 works great with PAR now :-). At present only for the records: IMHO the PoCo::Generic alt_fork implementation might need a similar fix [no actual need from my side though, but somebody may stumble on this in the future]. Cheers, Markus -Original Message- From: Rocco Caputo [mailto:rcap...@pobox.com] Sent: Saturday, July 30, 2011 9:56 AM To: POE Mailing List Cc: Markus Jansen Subject: Re: Problem to execute sidecar Perl scripts when compiling POE::Component::Resolver 0.912 with PAR Thanks for the clarification, Markus. I've applied a modified version of your patch as change 82af41c8ab2dd061acd7deb9979fa6cb5c4725ae. You can review it online at https://github.com/rcaputo/poe-component-resolver -- Rocco Caputo rcap...@pobox.com On Jul 29, 2011, at 05:01, Markus Jansen wrote: ... tiny correction of ^$X listed below, sorry for the typo ... /Markus -Original Message- From: Markus Jansen [mailto:markus.jan...@ericsson.com] Sent: Friday, July 29, 2011 10:40 AM To: Rocco Caputo; POE Mailing List Subject: RE: Problem to execute sidecar Perl scripts when compiling POE::Component::Resolver 0.912 with PAR Hi Rocco, thanks for coming back on this issue. Using the POE::Component::Resolver::Sidecar module is a good idea, though IMHO Module::ScanDeps should know that the module is needed via the use of \POE::Component::Resolver::Sidecar::main for Windows. The main problem is that while the [suboptimal] Windows solution would work for PAR, the standard [preferred] Unix solution does not for a number of reasons: - within PAR, $^X is set to perl @INC is set to [ par_unpack_path/inc/lib, par_unpack_path/inc/, CODE(..), CODE(..) ] - a perl executable does not exist inside the packed code (that is, at runtime under par_unpack_path) - instead, there is a limited Perl interpreter - one of the limits is that this interpreter cannot execute perl scripts via -e Each of the above effectively spoils the intended $^X -I @INC -M...Sidecar -e '...Sidecar-main()', i.e. the Sidecar execution via exec(). Due to the lack of -e support, one has to put use POE::Component::Resolver::Sidecar; POE::Component::Resolver::Sidecar-main(); into some ...Sidecar.pl file, and get that called. In the meantime, I have found that there are at least two ways to pack the above mini-script into a PAR executable (whether using the experimental --reuse switch or not is one of the details) and to get it called; hence, I would not like to dictate PAR users which of those ways to take, nor any naming conventions regarding the intermediate Sidecar.pl perl script. As a result, supplying the possibility to specify $sidecar_program seems to me the only general and lightweight way forward. Perhaps the change should come with a comment that the intended use is for PAR and similar modules, and should be used by experts who think they know what they are doing :-). Anyhow, my patch works great in production with the latest/greatest 2 PAR versions. Best regards, Markus -Original Message- From: Rocco Caputo [mailto:rcap...@pobox.com] Sent: Friday, July 29, 2011 6:54 AM To: POE Mailing List Cc: Markus Jansen Subject: Re: Problem to execute sidecar Perl scripts when compiling POE::Component::Resolver 0.912 with PAR Hi, Markus. It would seem that PAR (and other packaging tools?) can't find the Sidecar module because I neglected to actually use it. Please see the included patch, which resolves the missing Sidecar problem for Windows and anything else that detects use statements in the source. Do you ever supply a sidecar that isn't POE::Component::Resolver::Sidecar? A parameter would be excellent for a general-purpose sidecar-based module, but I think it's not so useful here. commit 638cd9e616a5b4ffbf413672784f41896de97430 Author: Rocco Caputo rcap...@cpan.org Date: Fri Jul 29 00:44:00 2011 -0400 Load the POE::Component::Resolver::Sidecar class. The presence of this module is requested on MSWin32. Resolves rt.cpan.org ticket 69172, reported by Gabor Szabo. diff --git a/lib/POE/Component/Resolver.pm b/lib/POE/Component/Resolver.pm index ff7ec8b..6614189 100644 --- a/lib/POE/Component/Resolver.pm +++ b/lib/POE/Component/Resolver.pm @@ -9,6 +9,8 @@ use Time::HiRes qw(time); use Socket qw(unpack_sockaddr_in AF_INET AF_INET6); use Socket::GetAddrInfo qw(:newapi getnameinfo NI_NUMERICHOST NI_NUMERICSERV); +use POE::Component::Resolver::Sidecar; + use Exporter; use base 'Exporter'; our (@EXPORT_OK) = qw(AF_INET AF_INET6); -- Rocco Caputo rcap...@pobox.com On Jul 15, 2011, at 06:17, Markus Jansen wrote: Hi Rocco, based on the excellent input I got so far from you and Steffen, I have now found a simple solution on the POE side without
Re: Problem to execute sidecar Perl scripts when compiling POE::Component::Resolver 0.912 with PAR
Thanks for the clarification, Markus. I've applied a modified version of your patch as change 82af41c8ab2dd061acd7deb9979fa6cb5c4725ae. You can review it online at https://github.com/rcaputo/poe-component-resolver -- Rocco Caputo rcap...@pobox.com On Jul 29, 2011, at 05:01, Markus Jansen wrote: ... tiny correction of ^$X listed below, sorry for the typo ... /Markus -Original Message- From: Markus Jansen [mailto:markus.jan...@ericsson.com] Sent: Friday, July 29, 2011 10:40 AM To: Rocco Caputo; POE Mailing List Subject: RE: Problem to execute sidecar Perl scripts when compiling POE::Component::Resolver 0.912 with PAR Hi Rocco, thanks for coming back on this issue. Using the POE::Component::Resolver::Sidecar module is a good idea, though IMHO Module::ScanDeps should know that the module is needed via the use of \POE::Component::Resolver::Sidecar::main for Windows. The main problem is that while the [suboptimal] Windows solution would work for PAR, the standard [preferred] Unix solution does not for a number of reasons: - within PAR, $^X is set to perl @INC is set to [ par_unpack_path/inc/lib, par_unpack_path/inc/, CODE(..), CODE(..) ] - a perl executable does not exist inside the packed code (that is, at runtime under par_unpack_path) - instead, there is a limited Perl interpreter - one of the limits is that this interpreter cannot execute perl scripts via -e Each of the above effectively spoils the intended $^X -I @INC -M...Sidecar -e '...Sidecar-main()', i.e. the Sidecar execution via exec(). Due to the lack of -e support, one has to put use POE::Component::Resolver::Sidecar; POE::Component::Resolver::Sidecar-main(); into some ...Sidecar.pl file, and get that called. In the meantime, I have found that there are at least two ways to pack the above mini-script into a PAR executable (whether using the experimental --reuse switch or not is one of the details) and to get it called; hence, I would not like to dictate PAR users which of those ways to take, nor any naming conventions regarding the intermediate Sidecar.pl perl script. As a result, supplying the possibility to specify $sidecar_program seems to me the only general and lightweight way forward. Perhaps the change should come with a comment that the intended use is for PAR and similar modules, and should be used by experts who think they know what they are doing :-). Anyhow, my patch works great in production with the latest/greatest 2 PAR versions. Best regards, Markus -Original Message- From: Rocco Caputo [mailto:rcap...@pobox.com] Sent: Friday, July 29, 2011 6:54 AM To: POE Mailing List Cc: Markus Jansen Subject: Re: Problem to execute sidecar Perl scripts when compiling POE::Component::Resolver 0.912 with PAR Hi, Markus. It would seem that PAR (and other packaging tools?) can't find the Sidecar module because I neglected to actually use it. Please see the included patch, which resolves the missing Sidecar problem for Windows and anything else that detects use statements in the source. Do you ever supply a sidecar that isn't POE::Component::Resolver::Sidecar? A parameter would be excellent for a general-purpose sidecar-based module, but I think it's not so useful here. commit 638cd9e616a5b4ffbf413672784f41896de97430 Author: Rocco Caputo rcap...@cpan.org Date: Fri Jul 29 00:44:00 2011 -0400 Load the POE::Component::Resolver::Sidecar class. The presence of this module is requested on MSWin32. Resolves rt.cpan.org ticket 69172, reported by Gabor Szabo. diff --git a/lib/POE/Component/Resolver.pm b/lib/POE/Component/Resolver.pm index ff7ec8b..6614189 100644 --- a/lib/POE/Component/Resolver.pm +++ b/lib/POE/Component/Resolver.pm @@ -9,6 +9,8 @@ use Time::HiRes qw(time); use Socket qw(unpack_sockaddr_in AF_INET AF_INET6); use Socket::GetAddrInfo qw(:newapi getnameinfo NI_NUMERICHOST NI_NUMERICSERV); +use POE::Component::Resolver::Sidecar; + use Exporter; use base 'Exporter'; our (@EXPORT_OK) = qw(AF_INET AF_INET6); -- Rocco Caputo rcap...@pobox.com On Jul 15, 2011, at 06:17, Markus Jansen wrote: Hi Rocco, based on the excellent input I got so far from you and Steffen, I have now found a simple solution on the POE side without any assumptions towards PAR (or whatever special system used, even with PAR there is more than one way to do it :-). The idea is simply to make $sidecar_program configurable, and leave the solution details to the application if special ones are needed. Find a possible [tested] patch below, and please consider it for integration in POE::Component::Resolver 0.913. Best regards, Markus
RE: Problem to execute sidecar Perl scripts when compiling POE::Component::Resolver 0.912 with PAR
Hi Rocco, thanks for coming back on this issue. Using the POE::Component::Resolver::Sidecar module is a good idea, though IMHO Module::ScanDeps should know that the module is needed via the use of \POE::Component::Resolver::Sidecar::main for Windows. The main problem is that while the [suboptimal] Windows solution would work for PAR, the standard [preferred] Unix solution does not for a number of reasons: - within PAR, $^X is set to perlfind @INC is set to [ par_unpack_path/inc/lib, par_unpack_path/inc/, CODE(..), CODE(..) ] - a perl executable does not exist inside the packed code (that is, at runtime under par_unpack_path) - instead, there is a limited Perl interpreter - one of the limits is that this interpreter cannot execute perl scripts via -e Each of the above effectively spoils the intended $^X -I @INC -M...Sidecar -e '...Sidecar-main()', i.e. the Sidecar execution via exec(). Due to the lack of -e support, one has to put use POE::Component::Resolver::Sidecar; POE::Component::Resolver::Sidecar-main(); into some ...Sidecar.pl file, and get that called. In the meantime, I have found that there are at least two ways to pack the above mini-script into a PAR executable (whether using the experimental --reuse switch or not is one of the details) and to get it called; hence, I would not like to dictate PAR users which of those ways to take, nor any naming conventions regarding the intermediate Sidecar.pl perl script. As a result, supplying the possibility to specify $sidecar_program seems to me the only general and lightweight way forward. Perhaps the change should come with a comment that the intended use is for PAR and similar modules, and should be used by experts who think they know what they are doing :-). Anyhow, my patch works great in production with the latest/greatest 2 PAR versions. Best regards, Markus -Original Message- From: Rocco Caputo [mailto:rcap...@pobox.com] Sent: Friday, July 29, 2011 6:54 AM To: POE Mailing List Cc: Markus Jansen Subject: Re: Problem to execute sidecar Perl scripts when compiling POE::Component::Resolver 0.912 with PAR Hi, Markus. It would seem that PAR (and other packaging tools?) can't find the Sidecar module because I neglected to actually use it. Please see the included patch, which resolves the missing Sidecar problem for Windows and anything else that detects use statements in the source. Do you ever supply a sidecar that isn't POE::Component::Resolver::Sidecar? A parameter would be excellent for a general-purpose sidecar-based module, but I think it's not so useful here. commit 638cd9e616a5b4ffbf413672784f41896de97430 Author: Rocco Caputo rcap...@cpan.org Date: Fri Jul 29 00:44:00 2011 -0400 Load the POE::Component::Resolver::Sidecar class. The presence of this module is requested on MSWin32. Resolves rt.cpan.org ticket 69172, reported by Gabor Szabo. diff --git a/lib/POE/Component/Resolver.pm b/lib/POE/Component/Resolver.pm index ff7ec8b..6614189 100644 --- a/lib/POE/Component/Resolver.pm +++ b/lib/POE/Component/Resolver.pm @@ -9,6 +9,8 @@ use Time::HiRes qw(time); use Socket qw(unpack_sockaddr_in AF_INET AF_INET6); use Socket::GetAddrInfo qw(:newapi getnameinfo NI_NUMERICHOST NI_NUMERICSERV); +use POE::Component::Resolver::Sidecar; + use Exporter; use base 'Exporter'; our (@EXPORT_OK) = qw(AF_INET AF_INET6); -- Rocco Caputo rcap...@pobox.com On Jul 15, 2011, at 06:17, Markus Jansen wrote: Hi Rocco, based on the excellent input I got so far from you and Steffen, I have now found a simple solution on the POE side without any assumptions towards PAR (or whatever special system used, even with PAR there is more than one way to do it :-). The idea is simply to make $sidecar_program configurable, and leave the solution details to the application if special ones are needed. Find a possible [tested] patch below, and please consider it for integration in POE::Component::Resolver 0.913. Best regards, Markus
RE: Problem to execute sidecar Perl scripts when compiling POE::Component::Resolver 0.912 with PAR
... tiny correction of ^$X listed below, sorry for the typo ... /Markus -Original Message- From: Markus Jansen [mailto:markus.jan...@ericsson.com] Sent: Friday, July 29, 2011 10:40 AM To: Rocco Caputo; POE Mailing List Subject: RE: Problem to execute sidecar Perl scripts when compiling POE::Component::Resolver 0.912 with PAR Hi Rocco, thanks for coming back on this issue. Using the POE::Component::Resolver::Sidecar module is a good idea, though IMHO Module::ScanDeps should know that the module is needed via the use of \POE::Component::Resolver::Sidecar::main for Windows. The main problem is that while the [suboptimal] Windows solution would work for PAR, the standard [preferred] Unix solution does not for a number of reasons: - within PAR, $^X is set to perl @INC is set to [ par_unpack_path/inc/lib, par_unpack_path/inc/, CODE(..), CODE(..) ] - a perl executable does not exist inside the packed code (that is, at runtime under par_unpack_path) - instead, there is a limited Perl interpreter - one of the limits is that this interpreter cannot execute perl scripts via -e Each of the above effectively spoils the intended $^X -I @INC -M...Sidecar -e '...Sidecar-main()', i.e. the Sidecar execution via exec(). Due to the lack of -e support, one has to put use POE::Component::Resolver::Sidecar; POE::Component::Resolver::Sidecar-main(); into some ...Sidecar.pl file, and get that called. In the meantime, I have found that there are at least two ways to pack the above mini-script into a PAR executable (whether using the experimental --reuse switch or not is one of the details) and to get it called; hence, I would not like to dictate PAR users which of those ways to take, nor any naming conventions regarding the intermediate Sidecar.pl perl script. As a result, supplying the possibility to specify $sidecar_program seems to me the only general and lightweight way forward. Perhaps the change should come with a comment that the intended use is for PAR and similar modules, and should be used by experts who think they know what they are doing :-). Anyhow, my patch works great in production with the latest/greatest 2 PAR versions. Best regards, Markus -Original Message- From: Rocco Caputo [mailto:rcap...@pobox.com] Sent: Friday, July 29, 2011 6:54 AM To: POE Mailing List Cc: Markus Jansen Subject: Re: Problem to execute sidecar Perl scripts when compiling POE::Component::Resolver 0.912 with PAR Hi, Markus. It would seem that PAR (and other packaging tools?) can't find the Sidecar module because I neglected to actually use it. Please see the included patch, which resolves the missing Sidecar problem for Windows and anything else that detects use statements in the source. Do you ever supply a sidecar that isn't POE::Component::Resolver::Sidecar? A parameter would be excellent for a general-purpose sidecar-based module, but I think it's not so useful here. commit 638cd9e616a5b4ffbf413672784f41896de97430 Author: Rocco Caputo rcap...@cpan.org Date: Fri Jul 29 00:44:00 2011 -0400 Load the POE::Component::Resolver::Sidecar class. The presence of this module is requested on MSWin32. Resolves rt.cpan.org ticket 69172, reported by Gabor Szabo. diff --git a/lib/POE/Component/Resolver.pm b/lib/POE/Component/Resolver.pm index ff7ec8b..6614189 100644 --- a/lib/POE/Component/Resolver.pm +++ b/lib/POE/Component/Resolver.pm @@ -9,6 +9,8 @@ use Time::HiRes qw(time); use Socket qw(unpack_sockaddr_in AF_INET AF_INET6); use Socket::GetAddrInfo qw(:newapi getnameinfo NI_NUMERICHOST NI_NUMERICSERV); +use POE::Component::Resolver::Sidecar; + use Exporter; use base 'Exporter'; our (@EXPORT_OK) = qw(AF_INET AF_INET6); -- Rocco Caputo rcap...@pobox.com On Jul 15, 2011, at 06:17, Markus Jansen wrote: Hi Rocco, based on the excellent input I got so far from you and Steffen, I have now found a simple solution on the POE side without any assumptions towards PAR (or whatever special system used, even with PAR there is more than one way to do it :-). The idea is simply to make $sidecar_program configurable, and leave the solution details to the application if special ones are needed. Find a possible [tested] patch below, and please consider it for integration in POE::Component::Resolver 0.913. Best regards, Markus
Re: Problem to execute sidecar Perl scripts when compiling POE::Component::Resolver 0.912 with PAR
Hi, Markus. It would seem that PAR (and other packaging tools?) can't find the Sidecar module because I neglected to actually use it. Please see the included patch, which resolves the missing Sidecar problem for Windows and anything else that detects use statements in the source. Do you ever supply a sidecar that isn't POE::Component::Resolver::Sidecar? A parameter would be excellent for a general-purpose sidecar-based module, but I think it's not so useful here. commit 638cd9e616a5b4ffbf413672784f41896de97430 Author: Rocco Caputo rcap...@cpan.org Date: Fri Jul 29 00:44:00 2011 -0400 Load the POE::Component::Resolver::Sidecar class. The presence of this module is requested on MSWin32. Resolves rt.cpan.org ticket 69172, reported by Gabor Szabo. diff --git a/lib/POE/Component/Resolver.pm b/lib/POE/Component/Resolver.pm index ff7ec8b..6614189 100644 --- a/lib/POE/Component/Resolver.pm +++ b/lib/POE/Component/Resolver.pm @@ -9,6 +9,8 @@ use Time::HiRes qw(time); use Socket qw(unpack_sockaddr_in AF_INET AF_INET6); use Socket::GetAddrInfo qw(:newapi getnameinfo NI_NUMERICHOST NI_NUMERICSERV); +use POE::Component::Resolver::Sidecar; + use Exporter; use base 'Exporter'; our (@EXPORT_OK) = qw(AF_INET AF_INET6); -- Rocco Caputo rcap...@pobox.com On Jul 15, 2011, at 06:17, Markus Jansen wrote: Hi Rocco, based on the excellent input I got so far from you and Steffen, I have now found a simple solution on the POE side without any assumptions towards PAR (or whatever special system used, even with PAR there is more than one way to do it :-). The idea is simply to make $sidecar_program configurable, and leave the solution details to the application if special ones are needed. Find a possible [tested] patch below, and please consider it for integration in POE::Component::Resolver 0.913. Best regards, Markus
Re: Problem to execute sidecar Perl scripts when compiling POE::Component::Resolver 0.912 with PAR
Hi Rocco,
based on the excellent input I got so far from you and Steffen, I have now
found a simple solution on the POE side
without any assumptions towards PAR (or whatever special system used, even with
PAR there is more than one way to do it :-).
The idea is simply to make $sidecar_program configurable, and leave the
solution details to the application if special ones are needed.
Find a possible [tested] patch below, and please consider it for integration in
POE::Component::Resolver 0.913.
Best regards,
Markus
diff -c
/vobs/cc/CCA-perl01/perl5_SunOS_sparcsixtyfive_char_path/prod/lib/site_perl/5.10.1/POE/Component/Resolver.pm
perl5/POE/Component/Resolver.pm
***
/vobs/cc/CCA-perl01/perl5_SunOS_sparcsixtyfive_char_path/prod/lib/site_perl/5.10.1/POE/Component/Resolver.pm
Wed May 4 04:39:59 2011
--- perl5/POE/Component/Resolver.pm Fri Jul 15 12:10:03 2011
***
*** 24,31
croak new() requires an even number of parameters if @args % 2;
my %args = @args;
! my $max_resolvers = delete($args{max_resolvers}) || 8;
! my $idle_timeout = delete($args{idle_timeout}) || 15;
my $af_order = delete($args{af_order});
if (defined $af_order and @$af_order) {
--- 24,32
croak new() requires an even number of parameters if @args % 2;
my %args = @args;
! my $max_resolvers = delete($args{max_resolvers}) || 8;
! my $idle_timeout= delete($args{idle_timeout}) || 15;
! my $sidecar_program = delete($args{sidecar_program});
my $af_order = delete($args{af_order});
if (defined $af_order and @$af_order) {
***
*** 73,78
--- 74,80
max_resolvers = $max_resolvers,
requests= { },
sidecar_ring= [ ],
+ sidecar_program = $sidecar_program,
}
);
***
*** 193,199
StderrEvent = 'sidecar_error',
CloseEvent = 'sidecar_closed',
Program = (
! ($^O eq MSWin32)
? \POE::Component::Resolver::Sidecar::main
: [
$^X,
--- 195,203
StderrEvent = 'sidecar_error',
CloseEvent = 'sidecar_closed',
Program = (
! defined $heap-{sidecar_program}
! ? $heap-{sidecar_program}
! : ($^O eq MSWin32)
? \POE::Component::Resolver::Sidecar::main
: [
$^X,
***
*** 444,449
--- 448,454
max_resolvers = 8,
idle_timeout = 5,
af_order = [ AF_INET6, AF_INET ],
+ # sidecar_program = $resolver_sidecar_program,
);
my @hosts = qw( ipv6-test.com );
***
*** 496,502
Create a new resolver. Returns an object that must be held and used
to make requests. See the synopsis.
! Accepts up to two optional named parameters.
af_order may contain an arrayref with the address families to
permit, in the order in which they're preferred. Without af_order,
--- 501,507
Create a new resolver. Returns an object that must be held and used
to make requests. See the synopsis.
! Accepts up to four optional named parameters.
af_order may contain an arrayref with the address families to
permit, in the order in which they're preferred. Without af_order,
***
*** 524,529
--- 529,538
# One at a time, but without the pesky blocking.
my $r3 = POE::Component::Resolver-new( max_resolvers = 1 );
+ sidecar_program controls how to start up a sidecar process;
+ this parameter is needed only in special environments such as PAR.
+ Solutions can be easily derived from the default code.
+
=head3 resolve
resolve() begins a new request to resolve a domain. The request will
Markus Jansen
Ericsson GmbH
Eurolab RD
Ericsson Allee 1
52134 Herzogenrath, Germany
Phone +49 2407 575 5157
Fax +49 22407 575 150
Mobile +49 172 2742003
markus.jan...@ericsson.com
www.ericsson.com
Ericsson GmbH. Sitz: Düsseldorf. Registergericht: Amtsgericht Düsseldorf, HRB
33012. Geschäftsführer: Stefan Koetz (Vors.), Nils de Baar, Bernd Schmidt.
Aufsichtsratsvorsitzender: Anders Runevad.
This Communication is confidential. We only send and receive email on the basis
of the terms set out at
www.ericsson.com/email_disclaimerhttp://www.ericsson.com/email_disclaimer.
inline: Picture (Metafile) 1.jpginline: Picture (Metafile) 2.jpg
