Re: asynchronous execution, was Re: implementing a set of queue-processing servers

Hi Perrin,

On Tuesday, November 26, 2002, at 06:14 PM, Perrin Harkins wrote:

> Bas A.Schulte wrote:
>> none of
>> them seemed to be stable/fast under heavy load even though I would 
>> have preferred that as it would allow me to do something to handle 
>> data-sharing between children via the parent which always seems to be 
>> in issue in Apache/mod_perl.
>
> What are you trying to share?  In addition to Rob's suggestion of using 
> a database table (usually the best for important data or clustered 
> machines) there are other approaches like IPC::MM and MLDBM::Sync.

I don't want to use a database table for the sole purpose of sharing 
data, I mean, I run the Apache/mod_perl servers to handle different 
components of our system, some run on top of a database and some of them 
don't.

Also, the things I would want to share are fairly dynamic things so a 
roundtrip to a database would probably add quite some overhead.

I have been looking at some of the IPC::Share* modules, the one I think 
I can use is (not sure here) IPC::ShareLite, but that darned thing won't 
install on my dev. machine (iBook/OS X) so I've been postponing things a 
bit ;)

My current plan is IPC::MM, stay tuned.


As to *what* I'm trying to share: I don't really know yet ;) Dynamic 
stuff like:

- what is a given child doing (to do things like: ok, I'm currently 
pushing data to some client in 5 children, and I don't want to have 
another child do this now so stuff this task in a queue somehere so I 
can process it later);
- application state. This is domain-specific so it's a bit hard to 
explain what I mean. I need serialized and *fast* access to this info so 
I would prefer not having this in my database.

NB: I posted a question on the first issue (look for "IPC suggestions 
sought/talking between children?" somewhere in the mod_perl mailinglist, 
I never seem to recall the proper archive site for it), didn't get any 
feedback on it as it probably goes beyond what someone would normally 
want from a web server.


>> BTW: I've been reading up a lot on J2EE lately and it appears more and 
>> more that a J2EE app server could quite nicely provide for my needs 
>> (despite all shortcomings and issues of course).
>
> What is it that you think you'd be getting that you don't have now?

Again; I don't know exactly but when I read stuff about entity-, 
session- and message beans, JMS etc., it has a lot of resemblance with 
what I'm currently doing "by hand" i.e. implement functionality like 
that on top of a "bare" Apache/mod_perl server.

A good example would be JMS: you get this "for free" (with JBoss 
anyway ;)) in a J2EE app. server but there's no obvious choice for us 
perl guys. There are some options I see now and then: Spread/Stem/POE, 
but none of these choices are obvious in the sense that they are being 
used by a lot of people to solve the type of problems JMS solves so 
there's really no one to turn to for advise; again, I'm building stuff 
between the raw metal and my own stuff.

BTW: with the issue on data-sharing: the same thing: I have raw metal 
(Apache/mod_perl and IPC:MM) and need to implement an API on top of them 
before I have the needed functionality. Again I'm building stuff again 
before I can solve my actual business problems.

I think these issues point out that we are missing *something*, I know 
*I* am :)

Regards,

Bas.