[rtg] buffering mechanism
bill fumerola
billf at mu.org
Wed May 24 14:58:54 EDT 2006
On Tue, May 23, 2006 at 01:59:18PM -0600, Leech, Jonathan wrote:
> Hello,
>
> We are considering using RTG at my company, and if so I will be making some enhancements.
>
> I see on the TODO list, #8. Add in buffering mechanism to buffer poll results in case the SQL database is down or unreachable, i.e. separate SQL insert thread pool.
>
> Does anyone have a particular architecture in mind, and if not, any objections to using a Message Queue? I found a nice intro article at http://www.ecst.csuchico.edu/~beej/guide/ipc/mq.html. I have used Named Pipes before, in a past life.
>
> Also I would be writing support for an Oracle database.
i already did this for mysql and released it to the public two years
ago:
http://mu.org/~billf/yrtg/
http://mu.org/~billf/yrtg/yrtg.patch
this work was never adopted into the rtg mainline. original posts/reposts
can be found at:
http://fireflynetworks.net/pipermail/rtg/2004-August/001151.html
http://fireflynetworks.net/pipermail/rtg/2005-August/001851.html
i'm sure the patch doesn't apply cleanly years later and unfortunately
i can't (well, i won't for free) split out just the buffer work from the
rest of the changes. if you look at rtgsqlbuf.c in that patch you should
be able to adopt whatever oracle hooks you want to use. the code was
intended to be written in such a way that db dependent and db agnostic
parts of the code are seperate. i never did pgsql support (ENOTIME) so
that's not tested, but the groundwork is certainly there.
also, there may be some freebsdisms in the code. setproctitle() perhaps.
good luck.
-- bill
disclaimer: i no longer work for yahoo!. i released this work with
permission while still an employee but it was a seperate derived work
(read: not the internal version).
More information about the RTG
mailing list