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 <n...@nickandperla.net> wrote: > On Tue, 5 May 2009 10:34:53 -0700 > Josh803316 <josh803...@gmail.com> 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: n...@nickandperla.net > http://search.cpan.org/~nperez/ <http://search.cpan.org/%7Enperez/> > http://github.com/nperez >