Showing posts with label perl. Show all posts
Showing posts with label perl. Show all posts

Sunday, September 24, 2017

cygwin-perl enable multithreading

Leave a Comment

I am using perl version 5.22 with cygwin. I am not able to figure out the problem in the following code. It looks like multi threading is not enable or something. When I ran the following code it just terminated without any message.

use warnings; use threads;  sub threaded_task {      threads -> create(sub {           print "Starting thread\n";         sleep(2);         print "Ending thread\n";       });  }  while(1) { threaded_task("arjun"); print "main thread\n"; sleep (2);  } 

64 bit config : enter image description here

32 bit config: enter image description here

0 Answers

Read More

Thursday, June 8, 2017

How do I make a PSGI program do costly initialisation only once per process, not per thread?

Leave a Comment

cross-post: http://perlmonks.org/?node_id=1191821

Consider app.psgi:

#!perl use 5.024; use strictures; use Time::HiRes qw(sleep);  sub mock_connect {     my $how_long_it_takes = 3 + rand;     sleep $how_long_it_takes;     return $how_long_it_takes; } sub main {     state $db_handle = mock_connect($dsn);     return sub { [200, [], ["connect took $db_handle seconds\n"]] }; } my $dsn = 'dbi:blahblah'; # from config file my $app = main($dsn); 

Measuring plackup (HTTP::Server::PSGI: Accepting connections at http://0:5000/):

› perl -MBenchmark=timeit,timestr,:hireswallclock -E"say timestr timeit 10, sub { system q(curl http://localhost:5000) }" connect took 3.0299610154043 seconds connect took 3.0299610154043 seconds connect took 3.0299610154043 seconds connect took 3.0299610154043 seconds connect took 3.0299610154043 seconds connect took 3.0299610154043 seconds connect took 3.0299610154043 seconds connect took 3.0299610154043 seconds connect took 3.0299610154043 seconds connect took 3.0299610154043 seconds 2.93921 wallclock secs ( 0.03 usr +  0.06 sys =  0.09 CPU) @ 107.53/s (n=10) 

Measuring thrall (Starting Thrall/0.0305 (MSWin32) http server listening at port 5000):

› perl -MBenchmark=timeit,timestr,:hireswallclock -E"say timestr timeit 10, sub { system q(curl http://localhost:5000) }" connect took 3.77111188120125 seconds connect took 3.15455510265111 seconds connect took 3.77111188120125 seconds connect took 3.15455510265111 seconds connect took 3.77111188120125 seconds connect took 3.64333342488772 seconds connect took 3.15455510265111 seconds connect took 3.77111188120125 seconds connect took 3.85268922343767 seconds connect took 3.64333342488772 seconds 17.4764 wallclock secs ( 0.02 usr +  0.09 sys =  0.11 CPU) @ 90.91/s (n=10) 

This performance is not acceptable because the initialisation happens several times, despite the state variable. How do you make it so it happens only once?

0 Answers

Read More

Sunday, August 14, 2016

How can I debug a custom debugger?

Leave a Comment

I wrote a custom debugger as described in perldebguts. There's something wrong with my debugger code, though, so I want to step through my DB::DB() and DB::sub() routines line-by-line to isolate the problem.

I suppose I can do this by setting $^D to 1<<30, since the documentation says:

When the execution of your program reaches a point that can hold a breakpoint, the DB::DB() subroutine is called if any of the variables $DB::trace, $DB::single, or $DB::signal is true. These variables are not localizable. This feature is disabled when executing inside DB::DB(), including functions called from it unless $^D & (1<<30) is true.

When execution of the program reaches a subroutine call, a call to &DB::sub (args) is made instead, with $DB::sub holding the name of the called subroutine. (This doesn't happen if the subroutine was compiled in the DB package.)

(emphasis added)

People on the IRC #perl-help channel said that with $^D & (1<<30) I may be able to debug my debugger but they didn't know any details beyond that.

How can I trace the execution of my DB::DB() and DB::sub() subroutines step-by-step?

UPD According to the answer below. When set $^D |= (1<<30) flag this allows me to debug debugger commands which is defined outside of DB namespace, but that is not an answer for question: How to disable that feature when executing inside DB::DB?

1 Answers

Answers 1

This is my custom debugger Devel::DebugHooks which I want to debug.

When I run this expression from debugger $^D|=(1<<30) and after that run debugger command, like vars 2 $x, this will allow me to debug code which is called from DB:: namespace.

This feature is disabled when executing inside DB::DB(), including functions called from it unless $^D & (1<<30) is true

This sentence from DOC just makes confusion.
The feature is NOT disabled when executing inside DB::DB() unless $^D & (1<<30) is true.
This feature is disabled only for functions called from DB::DB() when $^D & (1<<30) is true

Read More

Monday, April 4, 2016

Multi-site aware PSGI application development

Leave a Comment

The Plack::Builder allows mount multiple hosts, e.g. something as the following snippet:

my @sites = load_site_names(); my $apps; for my $site (@sites) {     $apps->{$site} = Some::PsgiFramework::MyApp->new( config => get_config($site) ); }  use Plack::Builder; builder {     for my $site (@sites) {         mount "$site" => $apps->{$site};     }     mount '/' => sub { ... }; } 

e.g.

  • the load_site_names returns a list of sites like http://example.com , http://some.other.site.com, ...
  • every "virtual-host" will use the same Some::PsgiFramework::MyApp
  • just their config is different

I need exactly the above - need develop one simple web-app which should be deployed for hunderts of different (low-traffic) sites and don't want setup an different PSGI server for each site.

However, the author of the Plack itself says (in the Plack::Request)

Note that this module is intended to be used by Plack middleware developers and web application framework developers rather than application developers (end users).

Writing your web application directly using Plack::Request is certainly possible but not recommended: it's like doing so with mod_perl's Apache::Request: yet too low level.

If you're writing a web application, not a framework, then you're encouraged to use one of the web application frameworks that support PSGI (http://plackperl.org/#frameworks), or see modules like HTTP::Engine to provide higher level Request and Response API on top of PSGI.

And this is the problem.

I checked many of different PSGI based frameworks in the MetaCPAN. And AFAIK each is singleton based, e.g. doesn't allows write applications which could be shared (mounted) many times for different sites in the same app.psgi.

So the questions are:

  • missed I something in the MetaCPAN (or in the docs), and here exists any (lighweight) web-framework which allows develop applications mountable many times in the app.psgi?
  • or i'm forced to develop Just Another My Own PSGI Framework? (To be honest, I not checked the catalyst - as it is too heavy-weight)
  • or just badly understand the "mounting"?

0 Answers

Read More

Monday, March 28, 2016

Why do I get the error “Thrift::TException=HASH(0x122b9e0)” when I try to execute a statement with Thrift::API::HiveClient?

Leave a Comment

I am trying to connect to Apache Hive from a Perl script but I'm getting the following error:

Thrift::TException=HASH(0x122b9e0) 

I am running with Hadoop version 2.7.0, Hive version 1.1.0, and Thrift::API::HiveClient version 0.003. Here is the script I am using:

#!/usr/bin/perl  use English; use Thrift::API::HiveClient;  connecttoHive();  sub connecttoHive {     my $client = Thrift::API::HiveClient->new( host => 'localhost', port => 10000 );      $client->connect() or die "Failed to connect";      $client -> execute('select count(1) from Koushik.emp2');     my $result = $client -> fetchAll(); } 

Could this be caused by a version issue or is it something else?


I also tried running the following script, which comes with the Thrift-API-HiveClient-0.003 distribution:

#!/usr/bin/env perl use lib 'lib'; use Data::Dumper; use Try::Tiny; use Thrift::API::HiveClient; #use Moose;  my ($host, $port) = (localhost => 10000);  try sub {   my $client = Thrift::API::HiveClient->new( host => $host, port => $port );   $client->connect;   print "Connected\n";   $client->execute(     q{ create table if not exists t_foo (foo STRING, bar STRING) }   );   $client->execute('show tables');   print Dumper $client->fetchAll;   print Dumper $client->getClusterStatus;   print Dumper $client->get_fields( 'default', 't_foo'); }, catch sub {   print "ZOMG\n";   print Dumper($_);   exit 1; }; 

I get the following output:

hduser@ubuntu:~/perl_script$ perl test-thrift.pl Connected ZOMG $VAR1 = bless( {                  'message' => 'Missing version identifier',                  'code' => 0                }, 'Thrift::TException' ); 

After enabling NOSASL authentication on my HiveServer2 by modifying the hive-site.xml, I am now getting a different error:

hduser@ubuntu:~/perl_script$ perl test-thrift.pl Connected ZOMG $VAR1 = bless( {                  'message' => 'Invalid method name: \'execute\'',                  'code' => 1                }, 'TApplicationException' ); 

It worked using Thrift::API::HiveClient2

hduser@ubuntu:~/perl_script$ cat test-thrift-client2.pl #!/usr/bin/env perl use lib 'lib'; use Data::Dumper; use Try::Tiny; use Thrift::API::HiveClient2; #use Moose;  my ($host, $port) = (localhost => 10000);  try sub {   my $client = Thrift::API::HiveClient2->new( host => $host, port => $port );   $client->connect;   print "Connected\n";   $client->execute(     q{ create table if not exists t_foo (foo STRING, bar STRING) }   );   $client->execute('show tables');   print Dumper $client->fetch; # print Dumper $client->getClusterStatus; # print Dumper $client->get_fields( 'default', 't_foo'); }, catch sub {   print "ZOMG\n";   print Dumper($_);   exit 1; };  hduser@ubuntu:~/perl_script$ perl test-thrift-client2.pl Connected $VAR1 = [           [             'drv_cdr_mp'           ],           [             'emp1'           ],           [             'emp3'           ],           [             'emp_1'           ],           [             'emp_bucket'           ],           [             'emp_incr_test'           ],           [             'emp_rslt'           ],           [             'log_detail'           ],           [             't_foo'           ],           [             'test1_emp1'           ]         ]; $VAR2 = ''; 

1 Answers

Answers 1

Since you are using HiveServer2, try using Thrift::API::HiveClient2. If that doesn't work, you could put some debug prints into the client to see if there is anything going on vis-a-vis the network, e.g. timeouts.

Read More