[jdev] Using chat room as resource pool -- need advice

[Bruce Campbell]

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.