Re: Avoiding runtime Session collision
Rodney Rindels <[EMAIL PROTECTED]> wrote on 05/02/2005 04:43:23 PM:
> I'm sure this is just my brain not properly doing a literal join. But
> I'm confused about how to properly ask the kernel what state a session
> is in,
> ie.
>
> Does a Session Exist?
> If so What state is the Session in?
> Avoiding shutdown until a Session is in state x or y ?
> Currently I am using sigtraps and handlers to shutdown the kernel, but
> It would be nice to extend that logic out if any of the Sessions I
> define are not in a "waiting" state, or don't have any wheels attached.
>
Handle all your signals and set a global $shutdown in the signal handlers.
Then have your sessions periodically check $shutdown and act appropriately.
> From what I've assembled thusfar, I'm guessing I'll have to alias all
> my sessions so I can know who to ask the kernel about.
>
> Basically every minute I have to fire an event that initiaties other
> sessions if those sessions are supposed to fire at that time of day. I'm
> assuming I'll have to keep some runtime information in a global about
> who fired and when as I don't see a shared kernel area for this type of
> data. In short I can never have two sessions of the same type running at
> the same time and have to avoid runtime collisions, as well as some of
> our customers only allow a single connection per day.
I'm not sure if I understand completely. But what is the session doing? I
guess you could:
my $session = $kernel->alias_resolve("mysession") || &start_mysession; #
but...
I guess I'm wondering if you are having seperate sessions be psuedo events
when instead you might want to have a session that can accept postings from
your scheduler? In other words why the ambiguity about whether or not a
session is active? Need more info here.
>
> A design concern I have is whether I'm going to have to keep my sessions
> around long term because of tracking their own behaviors as opposed as
> to like a shared kernel $_[HEAP] that could do that for me somehow
>
I always think of any data structure outside of the event definitions (i.e.
globals) as being something like the heap of the kernel? I don't think
there is anything wrong with this if that's your concern.
> Last question about _start. I notice that when you define a session, its
> _start runs immediately, is there a way to initiate a Session at
> daemonize time and not actually have it fire until it _start gets
> explicitly called.
>
Have your session's _start call something like
$kernel->yield('daemon_init') and then define a daemon_init handler. I
think that will run the first chance it gets after the kernel has started.
Then put everything you want in that handler.
> Rod
>
Avoiding runtime Session collision
I'm sure this is just my brain not properly doing a literal join. But I'm confused about how to properly ask the kernel what state a session is in, ie. Does a Session Exist? If so What state is the Session in? Avoiding shutdown until a Session is in state x or y ? Currently I am using sigtraps and handlers to shutdown the kernel, but It would be nice to extend that logic out if any of the Sessions I define are not in a "waiting" state, or don't have any wheels attached. From what I've assembled thusfar, I'm guessing I'll have to alias all my sessions so I can know who to ask the kernel about. Basically every minute I have to fire an event that initiaties other sessions if those sessions are supposed to fire at that time of day. I'm assuming I'll have to keep some runtime information in a global about who fired and when as I don't see a shared kernel area for this type of data. In short I can never have two sessions of the same type running at the same time and have to avoid runtime collisions, as well as some of our customers only allow a single connection per day. A design concern I have is whether I'm going to have to keep my sessions around long term because of tracking their own behaviors as opposed as to like a shared kernel $_[HEAP] that could do that for me somehow Last question about _start. I notice that when you define a session, its _start runs immediately, is there a way to initiate a Session at daemonize time and not actually have it fire until it _start gets explicitly called. Rod
Re: Sanity Check
Matt S Trout wrote: On Sat, Apr 30, 2005 at 10:19:04AM -0500, Wiggins d'Anconia wrote: I hate to say it but with all your various systems, protocols, etc. I would start from scratch with an XML based config system. I don't throw out XML lightly as I think it is overkill for a lot of things, but with all the different setups you are talking about it can be very effective. XML::Simple should do nicely. At least a couple of people are using my Class::XML to automatically load a tree of config objects from an XML file in a relatively clean format. I find it much less of a pain in the neck, anyway :) Yeah I'm sure i'm in over my head on this one :-). I'll take a look at Class::XML though, this almost goes beyond the XML::Simple comfort level. Thanks Everyone.. I'm POE'ing away now. Sure I will have 100 Million questions before this one is done. Rodney
Re: Sanity Check
Matt S Trout wrote: > On Sat, Apr 30, 2005 at 10:19:04AM -0500, Wiggins d'Anconia wrote: > >>I hate to say it but with all your various systems, protocols, etc. I >>would start from scratch with an XML based config system. I don't throw >>out XML lightly as I think it is overkill for a lot of things, but with >>all the different setups you are talking about it can be very effective. >> XML::Simple should do nicely. > > > At least a couple of people are using my Class::XML to automatically load > a tree of config objects from an XML file in a relatively clean format. I > find it much less of a pain in the neck, anyway :) > Looks interesting, more complex than I have ever needed. And I have never really used Class::DBI so it wouldn't be an easy jump for me. But I will certainly consider it in the future, especially for anything complex I get into. Been meaning to take Class::DBI for a test drive too. http://danconia.org
