Axton:
Since you bought up that point, I will ennumerate that plugins can do all of these operations too. Thus, my original point, they should be able to be placed on a separate thread.
And I like the single admin thread from a security standpoint.
James McKenzie
-----Original Message-----
From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Axton
Sent: Thursday, August 10, 2006 11:43 AM
To: [email protected]
Subject: Re: Multiple Admin Threads - Worthwhile?
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
