On Wed, 3 Jan 2001 13:52:43 -0800, Rob Bloodgood wrote:
>Hi, I'm working on my first POE program (using POE 0.1203). It's purpose is
>to replace a hodgpodge of patches, scripts, and procedures between my
>database and (extremely busy) webserver.
>
>WHOA.
>
>:-)
>
>I mostly get POE, I think. I've even got some working code. But still,
>there is some weirdness that I was hoping somebody could help me clear up.
>
>The design goals of this program are relatively simple. I have two sessions
>running, one to accept connections and one to hit the database.
>
>That being the case, I started with Socketfactory.perl as my starting point,
>to get me running w/ a tcp server out of the gate.
>(is there a "more efficient", "more idiomatic" way to do this? comments?)
POE::Component::Server::TCP. Later on you said it wasn't useful because it
doesn't support binding to specific interfaces. That's easily fixed, though.
Take a look inside; it's a very tiny wrapper around SocketFactory.
I'll add an interface parameter to it for 0.1204. If you can't wait that
long, patch it and send me a diff. :)
>Then I define a session that connects to the DB, reads some info from the
>DB, and then essentially waits for a watermark to go refresh that info.
>
>The idea is,
>once the info is pre-fetched
>I can serve it out via the tcp server
>without melting my database
>(and at roughly 500,000 hits/day, all server parsed, all requiring a DB
>touch, DB melt is a VERY serious issue. *EVEN* on a Sun 450 w/ 4x400 & 2GB
>of RAM!)
I think the traditional way to do this is to put a caching proxy between
your database and the outside world. Clients hit the proxy, which tests
the watermark and melts the database as needed. All other times, the
generated HTML is served directly from the proxy's cache.
>Then, when the info I've prefetched becomes stale, I want to send an event
>to my DBFetch session to begin the refresh process. The state machine idiom
>for this is particularly convenient, actually, because I can execute in one
>state, and fetch individual rows in the "read" state, while still serving
>hits to the server session.
>
>But now I run into issues.
>
>1) At first, I couldn't keep my DB session alive...
> however, I ended up solving that by creating an alias to it so I could
>access it from another state:
> # from StreamServerSession::gotline()
> # print the results of DBFetch::fetch out to the socket
> $kernel->call( db => fetch => $line, $heap->{wheel} ) or die "couldn't
>execute db::fetch: $!";
>
> But that seems kinda crufty... especially the passing of the wheel as a
>parameter in another session.
call() returns whatever a state did, so you could have db's fetch state
return whatever content, and the StreamServerSession could then send it:
$heap->{wheel}->put( $kernel->call( db => fetch => $line ) );
If DBFetch's fetch state will return the query value immediately, it may
as well be a plain perl function. POE state calls have a lot of overhead
you probably can do without.
If fetch is meant to run a while and post a response back, consider using
postbacks. They're sort of callbacks that post events instead, and they
make this sort of thing a little harder to implement but overall easier
to use.
>2) When my DB session is loaded, POE stops responding to SIGINT & Ctrl-Z
>altogether. I have to kill -TERM in another window to restart my program
>and test changes... YUCK! Now, I'm using DBD::Oracle, and I've seen this
>kind of thing before, but setting trace levels SHOWS the signals arriving! I
>just don't know where they're going.
This doesn't sound right. Can you provide more information about it?
>3) The socketfactory.perl sample used a "Package as Object" session idiom,
>so I went with it... if it ain't broke, right? So, following that
>convention I copied the constructor and object methods (even tho i actually
>use the HEAP for session info). So imagine my confusion at this output:
It may not be broken, but it also probably isn't the best method for
the job. Inline event handlers still are the fastest, but use whatever
works best.
Later you said you'd fixed #3, great!
[trace omitted]
-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
