Hi Chris,
Chris Browne wrote:
> I'm seeing some applications where it appears that there would be
> value in introducing asynchronous messaging, ala "message queueing."
> <http://en.wikipedia.org/wiki/Message_queue>
ISTM that 'message queue' is a way too general term. There are hundreds
of different queues at different levels on a standard server. So I'm
somewhat unsure about what problem you want to solve.
> c) There are lesser names, like isectd <http://isectd.sf.net> and the
> (infamous?) Spread Toolkit which both implement memory-based messaging
> systems.
If a GCS is about what you're looking for, then you also might want to
consider these: ensemble, appia or jGroups. There's a Java layer called
jGCS, which supports even more, similar systems.
Another commonly used term is 'reliable multicast', which guarantees
that messages are delivered to a group of recipients. These algorithms
often are the basis for a GCS.
> My bias would be to have something that can basically run as a thin
> set of stored procedures atop PostgreSQL :-). It would be trivial to
> extend that to support SOAP/XML-RPC, if desired.
Hm.. in Postgres-R I currently have (partial) support for ensemble and
spread. Exporting that interface via stored procedures could be done,
but you would probably need a manager process, as you certainly want
your connections to persist across transactions (or not?).
Together with that process, we already have half of what Postgres-R is:
an additional process which connects to the GCS. Thus I'm questioning,
if there's value for exporting the interface. Can you think of other use
cases than database replication? Why do you want to do that via the
database, then, and not directly with the GCS?
> It would be nice to achieve 'higher availability' by having queues
> where you might replicate the contents (probably using the MQ system
> itself ;-)) to other servers.
Uhm.. sorry, but I fail to see the big news here. Which replication
solution does *not* work that way?
Regards
Markus