Think of RPC as a POST and a simple queue as a GET. On Wed 04/16/14 01:41PM -0400, Mark Hahn wrote: > >I think this an interesting distinction, between RPC and simple queues. > >RPC relies on a client calling on a known remote server, where simple > >queues allow a horde of workers to pull messages off as they are > >available. I can see a use case for either depending on scale. > > I'm unforgivably implementation-oriented, but: whaa? > > a queue requires an RPC to enqueue and an RPC to dequeue, so it's > not as if there is any difference in scalability, security or > local/remote-ness. ie enqueing is a sort of fire-and-forget RPC that > doesn't do any work. > > I guess the main difference is really architectural: with queues as > the building block, you need an out-of-band, "meta" coordinator to > track success/completion, whereas the RPC approach can handle status > in-band. > > -mark
-- Gavin W. Burris Senior Project Leader for Research Computing The Wharton School University of Pennsylvania _______________________________________________ Beowulf mailing list, [email protected] sponsored by Penguin Computing To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
