Hey Guido,
I am the author of those modules. And yeah, they are broken and
experimental. I was attempting to create an unholy amalgamation of
MooseX::Declare and POE. It was an abomination that needed to be killed
with fire. I should make sure I clean up those modules.
That said, I had started h
None of this sounds particularly difficult, just a SMOP. The
interesting bits aren't getting the job server up and running. What
will be interesting is scaling the server. Am I correct to assume that
the workers now directly pull from the queue? And then you would be
changing that to a single queue
On Fri, 2 Nov 2012 13:12:58 +0530
Gokul Prasad wrote:
> Hi,
Can you nopaste a complete (non)working test case? Trying to help you
debug this piece meal isn't working. Also, explain what it is you are
trying to achieve? Perhaps you do not need to do something so
complicated.
--
Nicholas P
On Mon, 15 Oct 2012 10:11:32 +0300
Antti Linno wrote:
> 1) Do POE's sessions run in parallel?
Not unless you are forking.
> 2) Does POE::Component::Log4perl cure this problem?
Unknown. We need to see some code.
I could speculate on a number of things potentially causing this issue.
Are you
On Wed, 18 Apr 2012 15:57:27 +0300
Gabor Szabo wrote:
> How am I supposed to catch exceptions?
Please see "Exception Handling" in POE::Kernel.
--
Nicholas Perez
XMPP/Email: n...@nickandperla.net
https://metacpan.org/author/NPEREZ
http://github.com/nperez
On Wed, 11 Apr 2012 11:33:53 +0300
Gabor Szabo wrote:
> Hi,
>
> I have written a small POE script fetching web pages but it is leaking
> a lot of memory.
> I wonder if you could give me advice how to track down this memory
> leak?
>
> In a more generic question, are there special tools to debug
On Tue, 3 Apr 2012 16:57:59 +0300
Gabor Szabo wrote:
> my $ua = LWP::UserAgent::POE->new(timeout => 10);
> my $response = $ua->get($url) ;
At first glance without reading the documentation to this module, I
would say that this is wrong. Fetching the $url should be a
It would probably make sense to run the RCU in a child and have it push
events over the pipes of POE::Wheel::Run. Not as monolithic that way,
but then you could generalize what kind of interface those two pieces
use to chat. At that point you could then replace the RCU part with
anything else that
On Wed, 17 Aug 2011 14:46:51 +0200
Gunnar Strand wrote:
> I don't know anything about POE internals, but perhaps the
> internal flag for catching exceptions has been turned on somehow?
Hey Gunnar,
POE by default catches all exceptions that happen within event
handlers. It delivers these as DI
I do believe this is indeed a bug, but not in POE::Session. It seems
the GC semantics have changed somewhat and call() specifically invokes
a GC sweep in the cases where a return value is expected from an event.
I think this behavior is wrong (and I may have been the ultimate reason
this behavior
When the pre-packaged POE+DBI solutions don't work for you, you can
always spin up a child that talks to you via STDIN/STDOUT using
POE::Wheel::Run and performs the various DBI actions on your behalf.
Then define a simple command/reply interface using dumb hashes and
something like POE::Filter::Ref
On Sat, 20 Mar 2010 22:50:38 -0500 (EDT)
Philip Gwyn wrote:
> Currently, there is no way in POE to add meta-data to a request. And
> if we do something ourselves, we loose one of IKC's goals of being
> transparent, making remote sessions look like local.
>
> I've been pestering Rocco for over 1
On Tue, 9 Mar 2010 09:59:30 -0800
Zero Hero wrote:
> I'm trying to solve a common problem which occurs when I'm using
> PoCos. The crux of the issue is that a session doing a post to a
> PoCo, needs to stay alive for work done by a secondary post by that
> PoCo.
>
> Consider:
> 1. Session A
On Wed, 3 Mar 2010 17:13:39 +0100
"Winfried Neessen" wrote:
> Hi Martijn,
>
> > The solution to this is to write a custom filter that makes sure the
> > entire packet (your auth string/length/data) is read in before it
> > passes this on to your app.
> >
> thanks for your reply. I build a custom
On Thu, 3 Dec 2009 22:37:37 +0800
Ryan Chan wrote:
> On Wed, Dec 2, 2009 at 2:56 PM, Nick Perez
> wrote:
> > On Wed, 2 Dec 2009 12:42:34 +0800
> > Ryan Chan wrote:
> >
> >> If I goes with the fork solution, any abstraction recommended?
> >
> >
>
On Wed, 2 Dec 2009 12:42:34 +0800
Ryan Chan wrote:
> If I goes with the fork solution, any abstraction recommended?
I don't want to scare you off, but I can also suggest POEx::WorkerPool.
--
Nicholas Perez
XMPP/Email: n...@nickandperla.net
http://search.cpan.org/~nperez/
http://github.com/np
On Sun, 27 Sep 2009 10:59:48 +0800
"woosley. xu." wrote:
> $_[KERNEL]->sig_child("$pid, got_child_signal");
This is your problem line. Remove '$pid,' from the double quotes.
--
Nicholas Perez
XMPP/Email: n...@nickandperla.net
http://search.cpan.org/~nperez/
http://github.com/nperez
> );
>
> # Run the new sessions.
> POE::Kernel->run();
> },
> ErrorEvent => "worker_error",
> StdoutEvent => "worker_stdout",
> StderrE
On Tue, 5 May 2009 10:34:53 -0700
Josh803316 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-4a0076da5af9' already exists
> 23289: Remo
On Sun, 3 May 2009 03:19:00 -0400
Rocco Caputo wrote:
> On May 3, 2009, at 02:17, Roy M. wrote:
> >
> > On Sun, May 3, 2009 at 2:02 PM, Rocco Caputo
> > wrote:
> >> I don't understand the question. Do you mean to imply that an
> >> event-driven
> >> program cannot consume data from multiple
So I had some expectations out of EC's effort, but doesn't look like
the path being taken is one I necessarily want to follow. But it did
give me some ideas on integrating POE and Moose.
So I spent some time looking through various POE::Session
implementations: strengths, weaknesses, and raw idea
On Fri, 24 Apr 2009 19:32:11 -0500
johnr wrote:
> Hello,
>
> What is the POE way of accessing application configuration across
> sessions? I was working with Config::General (storing config info
> in a session's heap). However, that is not accessible by other
> sessions. What is the approach
subscribe=>[qw(poe://*/timeserver)],
> on_connect=>\&create_me,
> );
>
>
> Is there some sort of unpublish event if the worker goes away(crashes,
> etc...)? Would I have to code this into the server logic or it's
> already buil
If you read the docs for IKC you will see that it describes the publish
subscribe mechanism implemented for remote/local session subscription.
So basically, client would connect, subscribe to the server session,
publish its worker session, then post() an event to the server that
would then tell the
to mix/match?
>
> On Mon, Apr 20, 2009 at 5:47 PM, Nick Perez
> wrote:
>
> > It really sounds like you need to segregate the webapp from the
> > actual daemon. And with that, you do not need to run POE within
> > mod_perl (not that you could anyhow). But you obvious
It really sounds like you need to segregate the webapp from the actual
daemon. And with that, you do not need to run POE within mod_perl (not
that you could anyhow). But you obviously need POE communication
between the web server and the POE daemon. So I recommend using
POE::Component::IKC::ClientL
Don't get me wrong, POE and perl in general is really fast considering
that with a 800MHz Duron (I have ancient hardware, I know) I was able to
manage 45+ requests per second, including streaming, against a database
backend (SQLite) with my own home grown http server that incorporated
HTML::Tem
You are more than welcome to write an MUC module that makes use of the
tools available in PCJ, but PCJ itself is only a transport mechanism. We
are only building a connection broker. What you want to do with the
connection after it is established is beyond the scope of the project.
joe jiang wr
You should definitely use POE::Filter::XML. This is a shameless plug for
my own code, but it really solves the problem of implementing a push
parser that gives you meaningful chunks of data
(POE::Filter::XML::Nodes) from which you can process.
If you have any questions please let me know. Right
Oops. Reply went to Rocco but not the list: here it is.
-- Nick
--- Begin Message ---
I guess I should have sent my changes upstream which are in fact the
very same changes here. I use this in PoCo::Jabber::Client::XMPP and
also in Server::XMPP but adapted it for my own uses. I am not offering
t
From my own experience using ithreads versus POE with Wheel::Run and
without Wheel::Run with similar scripts that slam a server for requests
with a uniprocessor machine, there isn't much difference other than POE
provides a framework and some pretty slick pre-built components from the
community
Reply to me off list and I'll help you out :)
I am the author
Aaron Craig wrote:
Hi all.
I would desperately love to use POE. All of the introductory material
makes it sound like just the sort of thing I need.
A bit of background. I'm writing a simple IRC chatbot script as a favor
to a friend
I like array ref idea.
+1
Rocco Caputo wrote:
Dylan Hardison asked on IRC whether it was possible to limit the
length of an input line using POE::Filter::Line. I admitted that it's
not currently an option but could become one.
We put down some ideas about what to do with long lines. Four
possib
33 matches
Mail list logo
