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
