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
>
