Category Archives: poe

>MooseX::POE

Posted on by

>Started laying some of the foundation utility modules for the current app I’m working on.  Using MooseX::POE because I like the syntax over using MooseX::Declare and MooseX::POE::SweetArgs.  I don’t need that much sugar to enjoy my Kool-Aid! :)

So yeah, put together a simple wrapper class for getting input from a socket connection.  I looked at utilizing POEx::Role::TCPClient since that’s exactly the type of thing I’ve written a simplified version of, but it does not seem to work with the current release of POE.  *sigh*  (The incompatibility seems to be within POEx::Role::SessionInstantiation but I got lost looking down the rabbit hole on that one, maybe I’ll take another look after a few breaths of air).

So anyhow, I got that built then put together an app controller to handle everything.  Now I need to do some more thinking on my data requirements as far as what kind of backend is going to be needed.  More on that once I can finally nail down a decision on this…

Pin It

>Reflecting back..

Posted on by

>An interesting week this week, working on a variety of tasks. Unfortunately not all of it Perl related. :) I did get a chance to spend some time working with Reflex. Overall I really like how it ties into my Moose objects, with the only downside being things were quite flaky at runtime. A quick chat on #reflex reminded me of Rocco’s words from YAPC to use the git version until he has some time to put some polish on his recent changes and push out a release to CPAN.

While this thought was reassuring that things will work better once I pull from git, it also reminded me that I probably can’t really consider using Reflex for any production destined development. This would include my current project. :( i know POE will get the job done, it’s just not as clean and integrated as Reflex so it would have been nice.

Next week I’ll get back to scoping things out using MooseX::POE and see how it holds up. I think I’m already using that in one of my recent Moose objects and things are running sharply in production so sounds good. :)

Pin It

>testing code updates

Posted on by

>Tested my recent code changes today.  Things ran ok for about five minutes, then my cached data expired and I hit a few hiccups.  This was a good thing, in the process of tracking down where things went wrong I cleaned up quite a bit of the way things were being handled.  I’m still not thrilled with how I’m handling some of the asynchronous calls, but I just did not have time to fully rethink how things work on a fundamental level.  I know how I would do it were I to do it all over again, so I learn.. and we move on.  And should the current system fall over, I know how I’d like to fix it.  Hopefully that won’t ever be needed. :)

While I was testing I went ahead and debugged a couple web services I was utilizing that did not appear to behave as expected, worked out nicely to get my interactions with those cleaned up.

Overall pretty happy with how the system is running now, testing is complete, I’ve tagged the release v2.2.0 and will be pushing it to our production environments tomorrow morning.  I’d push it now, but honestly I need a good nights sleep and I’m not willing to risk it. :)

Pin It

>battling the parser!

Posted on by

>Today I finished up the refactoring that was needed to remove all the blocking code from my POE app.  I hate that they were in there to start with, but it looks good now.  I did have a bit of a fight with the web client module I swapped to, POE::Declare::HTTP::Client.  Apparently the old client module I was using had it’s own implementation of a HTTP parser, but this one uses HTTP::Parser, how original.  :)  I thought that was a good thing until it died from a bad header.  Checked the old client and it would take junk headers and relist them with the name Client-Junk: XXXX (replacing XXXX with the malformed header that was there to start with).  I’ve submitted a bug request to the web service I’m calling that has the malformed header, but how should I proceed?

At first I was going to submit a bug request to HTTP::Parser.  I looked into the code, found the line where it was dying because of a malformed header, and changed it so it didn’t die.  I mean, why should my application die over the format of content that I’m not in control of?  Sure, give me a warning, but don’t die.  Well, the more I thought about it, two things got to me about this logic.  First, this module has been around a long time behaving this way and there are numerous other places where the module dies.  It’s kind of fix them all or leave them be.  Second, Paul Finwick said it best with his Ferrengi talk at the past couple YAPC conferences.  Tis better to die than to return in failure.  Wrap that little shit in a try block sir :)

I went to the POE::Declare::HTTP::Client module, dug around and saw that it’s being accessed from POE::Filter::HTTP::Parser.  Wait, it’s already in an eval block.  Why the hell isn’t that catching the die?!?

*sigh* Maybe tomorrow I’ll figure it out. :)  Goodnight.

Pin It

>more on the user agent refactoring

Posted on by

>Things looked good with building the priority queue for handling web service requests, and I originally implemented it with a plan to provide support for callbacks.  Today I decided to use them, but felt things might get too sloppy with everything just being controlled by a Hashref of options/values.

Changed the system to use a WebServiceRequest object instead so I could control what was being passed in while leveraging some of Mooses type checking and coercions.  Lovely and simple.  Cleans up quite a bit of the handling code. I love it.
I searched through the codebase and found four places where we were using inline UA calls that were blocking.  This of course is not a good thing within an event based system (POE in this case), so I’m currently refactoring those to take advantage of the priority queue WebClient module.  I’ve finished refactoring two of those, tested and working.  Woot.  Two more to go.
Pin It

>refactoring the ua requests

Posted on by

>Currently a system I’m working on takes HTTP requests that it needs to send, but doesn’t really care much about the response, and tosses them over to a POE HTTP client that just sends in the background. The problem here is that it does each request concurrently. Normally that’s not an issue at all, but as it turns out if the web server you are sending these too gets overloaded and starts taking a long time to respond to request, all of a sudden you are driving up the load on my app server because of how many backlogged requests I’ve got danging concurrently.

Let’s find a solution for this.  Not a big deal, I don’t really care about the requests much so let’s just queue them up.  So rather than having the generic http ua session tossing things like wild, wrote up a quick WebClient module that maintains a queue of requests and handles them.  Since some requests are more important to others, let’s use a priority queue.  Simple to implement, but POE::Queue comes out of the box since we are already using POE, so we go with that.  For the HTTP client, I’m trying out POE::Declare::HTTP::Client.  I’ve had some issues with the generic component http client, so we’ll see if we fare any better with this one.

So…

Simple API. *check*
Queued requests to prevent overloading. *check*
Priority aware to take care of important things first. *check*
Optional callbacks in case we do care about the response. *check*

Sounds like a winner.  Writing up some test cases now, but looks good and functional.  Thanks CPAN for making this pretty damn easy to throw together. ;)

Pin It