{"_id":"55ed8caba872a80d00acff5d","__v":3,"githubsync":"","project":"55e94ebde5d0c623003ed868","version":{"_id":"55e94ebee5d0c623003ed86b","project":"55e94ebde5d0c623003ed868","__v":1,"createdAt":"2015-09-04T07:56:46.272Z","releaseDate":"2015-09-04T07:56:46.272Z","categories":["55e94ebee5d0c623003ed86c"],"is_deprecated":false,"is_hidden":false,"is_beta":true,"is_stable":true,"codename":"","version_clean":"0.3.0","version":"0.3.0"},"user":"55e94db887e942230032e40d","category":{"_id":"55e94ebee5d0c623003ed86c","pages":["55e94ebfe5d0c623003ed86e","55ed7fdadf21af2b009e217d","55ed86db2e66b621009941a6","55ed879428d7c33700de00e1","55ed88392e66b621009941a9","55ed885cec4c3e3900b75611","55ed88ba2e66b621009941ab","55ed8caba872a80d00acff5d","55ed8ce82e66b621009941c3","560d5df697a0a32f006e9de9","566ff8f33a32d20d00c45b37","5670195e81801f0d00802e1c"],"version":"55e94ebee5d0c623003ed86b","__v":12,"project":"55e94ebde5d0c623003ed868","sync":{"url":"","isSync":false},"reference":false,"createdAt":"2015-09-04T07:56:46.830Z","from_sync":false,"order":9999,"slug":"documentation","title":"Documentation"},"updates":[],"next":{"pages":[],"description":""},"createdAt":"2015-09-07T13:10:03.034Z","link_external":false,"link_url":"","sync_unique":"","hidden":false,"api":{"settings":"","results":{"codes":[]},"auth":"required","params":[],"url":""},"isReference":false,"order":5,"body":"Task scheduling follows these principles:\n\n  *     each task is assigned a *user*\n  *     users belong to *groups*\n  *     workers fetch tasks for *groups*, with a given priority\n\n Mapping a *user* to a *group *can be dynamic: the broker can be configured with a function which at runtime assigns a task to a group given the original userid.\n\nLoad can be assigned to different workers and the administrator can decide to give more priority to specific group of users.\n\nAn example can be useful in order to better understand:\n\n  *     there are two task types, for example \"sendemail\" and \"processhits\"\n  *     there are two groups of users, group \"gold\" and group \"poor\"\n  *     there are many users\n  *     there are 10 workers\n  *     workers are configure in order to process at most 10 tasks of type \"sendemail\" and at most 2 tasks of type \"processhits\" (which is a very CPU intensive task), but in total each JVM will be working to at most 10 tasks\n  *     8 workers are configured to take tasks for group \"gold\" and then for group \"poor\"\n  *     2 workers are configured to take tasks for group \"poor\" and then for group \"gold\"\n\nThis kind of configuration will give more working time to the \"gold\" users.\nWhen a task is submitted to the broker it is assigner to an user so, if we suppose that is a \"poor\" user, the tasks could remain in the system for some time because \"poor\" users have less resources and this impose a little bit of \"latency\" to the execution of the task submitted by them if the system is also working on tasks submitted by \"gold\" users.\nIf the user is promoted to the \"gold\" group his tasks are automatically assigned to the \"gold\" group and the waiting tasks will be processed immediately.","excerpt":"","slug":"task-scheduler","type":"basic","title":"Task Scheduler"}
Task scheduling follows these principles: * each task is assigned a *user* * users belong to *groups* * workers fetch tasks for *groups*, with a given priority Mapping a *user* to a *group *can be dynamic: the broker can be configured with a function which at runtime assigns a task to a group given the original userid. Load can be assigned to different workers and the administrator can decide to give more priority to specific group of users. An example can be useful in order to better understand: * there are two task types, for example "sendemail" and "processhits" * there are two groups of users, group "gold" and group "poor" * there are many users * there are 10 workers * workers are configure in order to process at most 10 tasks of type "sendemail" and at most 2 tasks of type "processhits" (which is a very CPU intensive task), but in total each JVM will be working to at most 10 tasks * 8 workers are configured to take tasks for group "gold" and then for group "poor" * 2 workers are configured to take tasks for group "poor" and then for group "gold" This kind of configuration will give more working time to the "gold" users. When a task is submitted to the broker it is assigner to an user so, if we suppose that is a "poor" user, the tasks could remain in the system for some time because "poor" users have less resources and this impose a little bit of "latency" to the execution of the task submitted by them if the system is also working on tasks submitted by "gold" users. If the user is promoted to the "gold" group his tasks are automatically assigned to the "gold" group and the waiting tasks will be processed immediately.