<snip> "It should stay that way." </snip> Ok. I'll bite. Why?
The discussions up to this point have been about altering the basic design of what is presently there, and perhaps a little bit about what the design should be. It's all theoretical. With this in mind, why not change what appears to be - well - a little tacky. Perhaps authentication should be moved off into it's own thread, and removed altogether from the administrative end. Another approach might well be to move the authentication component off and into it's own process. A thread is a thread is a thread. Unless the concern is about system resources and/or the management thereof (locks, races, etc) where is the issue? On Thu, August 10, 2006 4:16 pm, McKenzie, James J C-E LCMC HQISEC/L3 wrote: > Axton: > > > The login process is run through the admin thread. It should stay that > way. As to the breakout of other processes, great. > > > James McKenzie > > > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] On Behalf Of Axton > Sent: Thursday, August 10, 2006 12:50 PM > To: [email protected] > Subject: Re: Multiple Admin Threads - Worthwhile? > > > What are your perceived issues in regards to security with a > multi-threaded admin queue? I'm running it through my mind and not seeing > any security issues. I do see stability/reliability issues if poorly > designed, but that's another story. > > Axton Grams > > > On 8/10/06, McKenzie, James J C-E LCMC HQISEC/L3 > <[EMAIL PROTECTED]> wrote: > >> ** >> >> >> >> 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 >> >> >> >> __20060125_______________________This posting was submitted with HTML >> in it___ > > _________________________________________________________________________ > ___ > ___ > UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org > > > _________________________________________________________________________ > ______ > UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org > > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
