message queue process that is somehow forked or asynchronous

[NogDog]

I need to add functionality to an existing PHP 5.3 ( 🙁 ) app that will send messages to AWS Kinesis. With the PHP AWS SDK, that in itself seems straight-forward and pretty simple.

What I'm a bit concerned with is adding processing time or even errors/exceptions to the current request should this fail or lag. One option is to put the data of interest into a DB table or such, and have a separate cron job process that periodically. I was wondering if there's some way/tool to send the request in a forked process or something that becomes independent and the rest of the current process, which can then ignore it from that point forward, though I suppose I'd want that forked process to report errors somewhere?

Off to look at pcntl_fork now, which I seem to recall giving me a headache last time I looked.

[sneakyimp]

NogDog;11055625 wrote:

What I'm a bit concerned with is adding processing time or even errors/exceptions to the current request should this fail or lag. One option is to put the data of interest into a DB table or such, and have a separate cron job process that periodically. I was wondering if there's some way/tool to send the request in a forked process or something that becomes independent and the rest of the current process, which can then ignore it from that point forward, though I suppose I'd want that forked process to report errors somewhere?

Off to look at pcntl_fork now, which I seem to recall giving me a headache last time I looked.

It is definitely feasible to fork off a process. The last post in this other thread has an example I think. If I recall correctly, you need to fork a process with pcntl_fork and then in that other process you need to call [man]posix_setsid[/man]. The thread has some other discussion about reclaiming memory and whatnot. I don't recall exactly what we surmised about memory leaks for apache or whatever, but I do run this kind of stuff from various cronjobs (not apache) and it seems to work quite well.

NOTE, however, that you should probably still construct your message-sending script (the one you fork off) to loop a few times in case things fail. If you want truly reliable message delivery, you not only have to hang around and wait for the gateway to respond, you need to properly handle timeouts from the gateway (possibly for a loooong time if it's down) and also you need to try again if some temporary error refuses your message. I think a database is very important for this kind of thing -- as a ************* to communicate between your processes and apache or as a way to track the success or failure (and possible error messages) returned by your message-sending processes.

[NogDog]

Yeah, part of me is leaning toward a DB table and cron job just for the retry ability along with hopefully abating worries of zombie processes and such, but it just feels ugly. 🙂

[sneakyimp]

NogDog;11055629 wrote:

Yeah, part of me is leaning toward a DB table and cron job just for the retry ability along with hopefully abating worries of zombie processes and such, but it just feels ugly. 🙂

Then it's a choice between two uglies:
you have a database queue of messages to be delivered (not ugly at all IMHO)
you have long-lived, indepdendent, zombie processes that may try over and over forever and never die until you eventually use up all your server memory and your server crashes.
While the likelihood of the latter problem might be pretty remote in practice, it can happen. You should try to avoid situations where you fork off processes that never die. Whether you have a db or not, you will probably have to work some logic into the processes you fork so that they can self-evaluate so they know when to quit and clean up after themselves. I'd also point out that if you construct these processes to send you email in the event of a failure, then you are inviting a billion emails one day when something breaks.

It's been my experience that multi-process situations are tricky and it's helpful to have their logging and status update type stuff written to a db so you can slice it and dice it. Every process should identify itself when logging (see [man]posix_getpid[/man]) or otherwise it can be tricky to know which log entries belong to which process which, in turn, can make it hard to identify what caused the error.

To me the ugly bit gets introduced the minute you start talking to some remote API or gateway. These remote systems will always go flaky at some point, if only temporarily.

[sneakyimp]

Let me also add that a DB can be extremely handy if you want to collect any kind of analytics about your message delivery functionality. DB can be used for:
queuing messages to be delivered (or at least storing or queuing messages that couldn't be delivered by your forked process)
writing errors such that errors belonging to a specific process are stored with their process id and possibly other information (like user id, date, time, etc.)
* storing analytics like success rates and failure rates.

[NogDog]

Note to self: be sure to abstract the writing of the messages in the app itself so it doesn't need to know which way I do it, and then what I change to next week, and then next month.... 😉

[sneakyimp]

NogDog;11055635 wrote:

Note to self: be sure to abstract the writing of the messages in the app itself so it doesn't need to know which way I do it, and then what I change to next week, and then next month.... 😉

It may not be advisable or possible to separate them entirely. My guess is that your message-sending scripts might need certain information that your app has: db credentials, API credentials, probably some other information (e.g., who to send email to if things go bad). On the other hand, your code in your app that wants to send the message probably wants to just hand the message off to some reliable subsystem that'll bust its hump to make sure the message gets through. Abstracting the message delivery code and providing a nice clean interface point will make life easier in your main app.