On Tue, 5 May 2009 15:54:13 -0700
Josh803316 <[email protected]> wrote:
> Yes, thanks to some members of the list I have been taught that this
> is indeed correct and not a bug. Makes more sense now.
>
> I was trying to spawn a worker child but wasn't spawning it correctly
> therefore the process was indeed inside the same kernel. I'm now
> using a wheel::run to spawn the child process and then have the ikc
> client connect. I'm sure there is a more elegant way to do this but I
> need the portability of the clients spawning locally as different
> processes, or on remote machines that would connect back to the
> server.
>
> (Inside the worker template package)
> sub __spawn {
> my $class = shift;
>
> POE::Session->create(
> inline_states => {
> _start => \&create_ikc_client,
> worker_stdout => \&worker_stdout,
> worker_stderr => \&worker_stderr,
> worker_error => \&worker_error,
>
> },
> args => [ $class ]
> );
>
> }
>
> sub create_ikc_client{
> my ( $kernel, $heap, $class ) = @_[ KERNEL, HEAP, ARG0 ];
>
> my $child = POE::Wheel::Run->new(
> Program => sub{
> my ( $kernel, $heap ) = @_[ KERNEL, HEAP ];
>
> # Wipe the existing POE::Kernel clean.
> POE::Kernel->stop();
> print STDERR "Worker forked\n";
>
> my $addr = $class->IP || '127.0.0.1';
> my $port = $class->PORT || 5667;
> my $trace = $class->TRACE || 0;
> my $debug = $class->DEBUG || 0;
>
> POE::Component::IKC::Client->spawn(
> ip => $addr,
> port => $port,
> name => "Client$$",
> on_connect => sub {
>
> POE::Session->create(
> package_states =>
> ## extract all
> subroutines that don't start with "__"
> ## and allocate
> them as states:
> [
> (__PACKAGE__)
> => [ do {
> no
> strict 'refs';
> grep {
> !/^__/ and defined &$_ } keys %{ __PACKAGE__ . "::" };
> } ],
> ($class)
> => [ $class->SUBSCRIBE_METHODS ]
>
> ],
> ## pass args into
> _start:
> args => [$class],
> options =>
> { trace => $trace, debug => $debug },
>
> );
> },
> on_error => sub {
> my ( $kernel ) = $_[ KERNEL];
> print STDERR Dumper($kernel);
> }
>
> );
>
> # Run the new sessions.
> POE::Kernel->run();
> },
> ErrorEvent => "worker_error",
> StdoutEvent => "worker_stdout",
> StderrEvent => "worker_stderr",
> CloseEvent => "worker_close",
>
> ) or die "$0: can't POE::Wheel::Run->new";
>
> $heap->{worker} = $child;
>
> return $child;
> }
>
> On Tue, May 5, 2009 at 3:41 PM, Nick Perez <[email protected]>
> wrote:
>
> > On Tue, 5 May 2009 10:34:53 -0700
> > Josh803316 <[email protected]> wrote:
> >
> > > It appears that if you start an IKC server and then an ikc client
> > > connects to it from within the same POE::Kernel->run() then we get
> > > the following error:
> > >
> > > 23289: Remote kernel 'host.domain-4a0076da00005af9' already exists
> > > 23289: Remote kernel 'host.domain-4a0076da00005af9' already exists
> > >
> > > Single program flow:
> > >
> > > POE::Component::IKC::Server->spawn();
> > > POE::Component::IKC::Client->spawn();
> > >
> > > POE::Kernel->run();
> > >
> > > This is where we get the run time error from the client about the
> > > remote kernel already existing. The error doesn't seem to affect
> > > anything else but I assume this is either a bug or I'm doing
> > > something wrong.
> >
> >
> > Erm, you do realize that IKC is mostly for inter process
> > communication right? Running both within the same kernel (process)
> > and it throwing that warning is /exactly/ what it should be doing.
> >
> > --
> >
> > Nicholas Perez
> > XMPP/Email: [email protected]
> > http://search.cpan.org/~nperez/ <http://search.cpan.org/%7Enperez/>
> > http://github.com/nperez
> >
Wouldn't it be simpler to write the server, write the client, and
manage the processes externally either via daemontools or runit? You
are going to need to package up the client anyhow if you want to run
it remotely.
--
Nicholas Perez
XMPP/Email: [email protected]
http://search.cpan.org/~nperez/
http://github.com/nperez
