Stopping Threads versus Denying Resources


Franco Zambonelli (franco.zambonelli@unimo.it)
Sun, 18 Apr 1999 18:03:18 +0200


Hi to you all. I find the problem of controlling res. cons. on JVMs very important and I hope next JDK releases will support this feature. However, given the availability of appropriate monitoring mechanisms, and given that one discover that an agent/code module is consuming too many resources, what can we do? 1) force the termination of those agents/code modules (i.e., JVM thread) consuming too much resources Apart from the low-level problems involved, as discusses in previous mails, this is not a general solution. Some agents (let me use this term) may not be malicious, but simply huge. In these cases, it would be cruel to destroy them. If we have decided to accept an agent and have opened our resources to it, we have also to find a way to tell the agent IN ADVANCE that we do not want it to consume more than an amount X of resources. Otherwise, we have to find an elegant way to let it (or its owner) autonomously decide to stop activity. For example 2) by denying to it the access to the resources, as suggested by Doug Lea in its last mail However, this is likely to complicate the agent code, because it has to handle this kind of exceptions. The situation is even worse if we revoke the resources it is currently using. A third, more elegant solution could be 3) to pretend the resources the agent is looking for are no longer available This technique is likely to apply in several application cases: a) If an agent is arrived on a site to look for execution resources (load balancing) we could give it low-priority thus letting the agent (or the load balancing tool that controls its movements) assume that the site is overloaded and that it is better to go to another site to execute b) if the agent is on a site to access to specific services, by degrading the quality of the services offered to it. c) If an information retrieval agent overloads a node because it issues too many queries, by starting answering "NO MATCH" to all its queries IMHO, the more general solution is to 4) assign prices to resources and to let agents access to them only if it can pay However, if the agent does not want to pay we have to decide what to do, that is points 1, 2 or 3. In my research on mobile agents, I have defined a reactive tuple space architecture to be used by agents to access to the local resources on a node (see MA '98 proceedings or, better, my project page http://sirio.dsi.unimo.it/MOON). The reactive capabilities of the tuple space can be used to actively monitor the agents' activities in accessing to the local resources and to dynamically change the behaviour of the tuple space so to, say, deny to agents the access to specific resources (by pretending there are no matching tuples). I intend to extend the tuple space capabilities in order to support resource pricing and accounting. However, the effective implementation of these features requires capabilities not present in the current JVM. Hope my mail may be of interest to someone. Comments are welcome (even those stating that I have written a lot of stupid sentences. I'm quite new in this research area.... ;-) Franco Zambonelli _______________________________________________________________________________ Franco Zambonelli Dipartimento di Scienze dell'Ingegneria - Universita' di Modena e Reggio Emilia Via Campi 213\b - 41100 Modena - ITALY Office Phone: +39-059-376735 Home Phone: +39-051-271988 Fax +39-059-376799 E-Mail: franco.zambonelli@unimo.it Homepage: http://www.dsi.unimo.it/Staff/st35/Zambonelli.idc _______________________________________________________________________________ ---------------------------------------------------------------------------- To unsubscribe (or other requests) mailto:majordomo@media.mit.edu List archives, FAQ, member list, etc. http://gee.cs.oswego.edu/dl/javares/



This archive was generated by hypermail 2.0b3 on Thu Mar 18 1999 - 12:31:15 EST