[Swift-devel] Support request: Swift jobs flooding uc-teragrid?

Ti Leggett leggett at mcs.anl.gov
Wed Jan 30 10:00:36 CST 2008


On Jan 30, 2008, at 01/30/08 09:48 AM, Ben Clifford wrote:

[snip]

> No. The default behaviour when working with a user who is "just  
> trying to
> get their stuff to run" is "screw this, use GRAM2 because it works".
>
> Its a self-reinforcing feedback loop, that will be broken at the point
> that it becomes easier for people to stick with GRAM4 than default  
> back to
> GRAM2. I guess we need to keep trying every now and then and hope  
> that one
> time it sticks ;-)
>
> -- 

Well this works to a point, but if falling back to a technology that  
is known to not be scalable for your sizes results in killing a  
machine, I, as a site admin, will eventually either a) deny you  
service b) shut down the poorly performing service or c) all of the  
above. So it's in your best interest to find and use those  
technologies that are best suited to the task at hand so the users of  
your software don't get nailed by (a).

In this case it seems to me that using WS-GRAM, extending WS-GRAM and/ 
or MDS to report site statistics, and/or modifying WS-GRAM to throttle  
itself (think of how apache reports "Server busy. Try again later") is  
the best path forward. For the short term, it seems that the Swift  
developers should manually find those limits for sites that the users  
use regularly for them to use, *and* educate their users on how to  
identify that they could be adversely affecting a resource and  
throttle themselves till the ideal, automated method is a usable  
reality.



More information about the Swift-devel mailing list