OK, for starters let me say that I'm getting all of this working on a
largely monkey-see, monkey-do basis... the stuff in /samples was invaluable
for getting started, but somehow I doubt that if you were to re-write them
now, most of them would be quite different. :-)
> 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. :)
Well I was going to do that...
but something's broken now, and socketfactory.perl complains:
Bad arg length for Socket::unpack_sockaddr_un, length is 16, should be 110
at ./socketfactory.perl line 306.
> 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.
You don't know *how* much I wish this was something traditional... :-)
Seriously, tho, I'm writing this app because the operations I was doing on
my database involved record locks that if mismanaged even a little tiny bit
would lock the whole company... <SHUDDER>
> > 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.
OK, first point: I was mostly wondering if defining the alias for the
session was the "approved" way to keep it alive.
2nd point: for this stage of development it returns immediately, but based
on the suggestion and pseudocode I got from Torvald Riegel, and the
drastically unclear documentation explaining them (sorry :-), I managed to
switch my call() to a postback().
The hardest part was figuring out who/what, in my program, corresponded to
the Servlet & Client in the docs.
Now before you take umbrage at the documentation crack, let me say that I'm
pretty sure that most of the intent for postbacks, as originally designed,
was related first to Tk, and then in wrapping existing callbacks.
A) all of the documented examples for postback mention Tk
B) the only mentions of postback in the samples are in tk.perl
( except for the passing note in names.pl that this section is now obsolete,
because we now have session postbacks :-)
Since I've only rarely used callbacks before (mostly in HTML::Parser's), the
connection to the framework I'm in right now was a little while in coming.
HOWEVER,
after plugging at it for awhile, my flow now works like this:
StreamServerSession::got_line {
my ($object, $sender, $kernel, $heap, $line) = @_[OBJECT, SENDER,
KERNEL, HEAP, ARG0];
# bookkeeping here...
$kernel->post( db => fetch => $line, $sender->postback( reply =>
$line ) );
}
(what is $sender all about, anyway?)
DBFetch::fetch {
# do stuff to find the $answer
$postback->($answer);
if ($since >= WATERMARK) {
$since = 0;
$heap->{running_update} = 1;
$kernel->yield('update_acctid');
}
}
StreamServerSession::reply {
my ($object, $heap, $request, $response) = @_[OBJECT, HEAP, ARG0, ARG1];
# print "$object: printing response: @$response\n";
$heap->{wheel}->put(@$response);
}
I'm just going to venture a guess here, but is this kind of thing the
"correct" way to do what you said you were too lazy to do correctly in
tutorial-chat.pl?
Also,
I'm curious about how the whole $wheel->put mechanism fits with the
"flushed" state.
> >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?
Actually, I'm going to have to call this a DEFINITE Oracle issue. When I
got a little further and was able to tell my DB session to shutdown, and I
mean from the MOMENT the db handle was disconnected, my POE program reponded
to Ctrl-C. This is consistent with the behavior I've seen in other Perl
programs that use DBD::Oracle. SIGINT responds only if there is a currently
executing statement handle, BEFORE it returns... at that point SIGINT gives
an Oracle message:
DBD::Oracle::st fetch failed: ORA-01013: user requested cancel of current
operation (DBD ERROR: OCIStmtFetch) at $0 line __LINE__
It may be a task of major wizardry (translated: hours of digging thru
obscure callbacks, XS, and OCI) to find this...?
And finally:
I would like to have a way to stop my server via a message to my daemon thru
the socket, like:
if ($line eq 'quit') {
$kernel->alias_remove('db'); # kills the DBFetch thread
return;
}
Now, that's a snippet of my actual code, and it causes everything to quit
except the TCPServer. How would you suggest I signal the SocketFactory to
shut down?
TIA, and thanx for creating such a FRICKIN COOL module. ;-)
L8r,
Rob
