On Mon, 13 Feb 2006, Matthew Wilson wrote:
We have a bunch of boxes (20 or so) that offer web-services to our
server farm of several hundred boxes. Right now, if a box on a farm
needs to connect to one of the web service boxes, it iterates through
a list of all the web-service boxes, and tries to connect to each one,
until it finds one that is free to handle the request.
Yick. Your current selection method sucks.
I'm thinking that a better model might be to create a MUC where each
of the web-service boxes are persistently connected. They would use
their presence attribute to indicate whether they are available or
busy.
I'd prefer that the clients and servers communicate through the room,
rather than directly, so that I can just log the chat room and see all
the transactions.
I'd avoid the MUC (central dependency) and rely on Jabber servers on a few
boxes to establish inter-server connections.
A few questions:
* Is this asinine?
It depends on the application really.
* Has anyone done anything like this?
Yes. Code is even available[1].
Are there any hidden gotchas
you discovered?
Essentially, you are wanting to use Jabber as a method to select the
'most' available host. Now, whilst you can do this, and it will work,
there are three gotchas:
a) Jabber has high latency compared to dedicated methods:
The time for each web server JID to report back its
process state to the chat room/other JIDs may well be
longer than the time to process the request; any such
information may well be out of date.
b) Jabber has high latency compared to dedicated methods:
The time taken to receive the roster on each connection
may well be longer than the client wishes to wait. If you
do implement this, do not connect to Jabber each time you
wish to find an appropriate server; maintain persistent
connections and write the current 'best' choice to a
known file or socket.
c) Jabber is object based, not stream based:
The fundamentals of Jabber are packets, and before any
Jabber-processing does anything with the packet, it needs
to have the full packet in its grubby little hands. Thus,
sending the web request via Jabber and expecting to
receive a timely reply is somewhat foolish.
In the situation you have described, you would be better served by
avoiding Jabber; put a web load balancer in front of your web farm.
--
Bruce Campbell
[1] I have proof of concept code available privately that sends received
web requests via Jabber off to a master JID and waits for replies
via Jabber, but the gotchas described above really kill the
performance.
