The problem is that the approval server, sla, cmdb, etc. manipulate workflow (approval creates notification filters, cmdb creates forms, sla creates event filters). These operations can only be performed using the admin queue.
The main reason I brought this is because at times we have a large number of developers (up to 8) working on a single server. Whenever one developer does something that uses the admin queue, all other developers are forced to wait on that users operation to complete because there is only 1 thread. It would be nice if there were multiple threads, and the system was designed such that the only time an admin thread is blocked is when two threads attempt to use a common resource. Why do you like the idea of a single admin thread? Axton Grams On 8/10/06, McKenzie, James J C-E LCMC HQISEC/L3 <[EMAIL PROTECTED]> wrote:
** Axton: I like the idea that there is only one admin thread, but I would like to comment on the cmdb, approval server, etc. blocking this thread. It should be possible to separate them out into their own threads on a per-purpose basis. James McKenzie -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Axton Sent: Thursday, August 10, 2006 11:05 AM To: [email protected] Subject: Multiple Admin Threads - Worthwhile? I wanted to get a sense of whether people thought having a multi-threaded admin queue would be a good thing for a Remedy server. In other development environments/efforts, people are able to checkout/commit portions of code, thus only blocking operations related specifically to those objects. In the arsystem, all admin operations are blocked by any admin operation. This would address many problems this presents with the arsystem environment: - Multiple developers - Processes that use the admin queue (approval server, cmdb, etc.) not occupying the queue from other, unrelated operations Though, at the same time, it would introduce inherent complexities within the arsystem server: - Granular object locking (locked at the api operation level, not an object checkout model) - Thread collisions due to recursive operations The questions are these: - Do you feel this would be a worthwhile time investment on BMC's part? - Would this ease contentions in your environment? - Do you think the BMC engineers are up to it? I am anxious for your thoughts. Axton Grams _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org __20060125_______________________This posting was submitted with HTML in it___
_______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
