Am 21.04.2009 um 14:12 schrieb John Mazzitelli:
[ About a resource that shows up in the AD portlet, but that the user
never wants to import and
l8er even physically removes ]
> If you want to ignore it, choose to IGNORE it in the auto-discovery
> portlet or queue page.
It could make sense to have a "get rid" button in the "advanced page"
that completely removes
it from inventory and not just having the resource the user never
wanted stay in inventory
in IGNORED state forever.
It scans the registry for the list of installed windows programs using SIGAR - see WindowsSoftwareDelegate.
I doubt deleting will uninstall :) I think that just deletes the package definition in the DB.
----- Original Message -----
From: "Ian Springer" <ispringe(a)redhat.com>
To: "John Mazzitelli" <mazz(a)redhat.com>
Cc: "jopr-dev" <jopr-dev(a)lists.jboss.org>
Sent: Friday, April 17, 2009 6:57:19 PM GMT -05:00 US/Canada Eastern
Subject: Re: [jopr-dev] platform content discovery
Cool! How did you get the installed programs on Windows - is that a
SIGAR API? Does the Delete button actually work?
On 4/17/2009 4:47 PM, John Mazzitelli wrote:
> I have this re-enabled on my box. I won't be checking in until after we release, but... in case you never saw this before, see attached.
> It's platform content discovery. Notice you can see what software I have installed on my windows box and my linux/fedora box.
> jopr-dev mailing list
I have this re-enabled on my box. I won't be checking in until after we release, but... in case you never saw this before, see attached.
It's platform content discovery. Notice you can see what software I have installed on my windows box and my linux/fedora box.
I'm attempting to fix http://jira.rhq-project.org/browse/RHQ-1930.
I need my latest checkin (rev 3634) peer reviewed and tested. I ran it over here and it looks like its working (even stepped thru a debugger to see it working).
I basically wrap calls to the discovery components in a proxy that times out the invocations if the component takes too long (30 seconds hardcoded - yes, it needs to be configurable, that would be nice :)
Do you see anything missing?
There is one thing I already know about: the thread pool can grow unbounded if a discovery component is misbehaved. In other words, if a discovery component's discoverResource method consistently deadlocks or enters an infinite loop, our thread pool will grow unbounded until we run out of mem (i.e. if we run discovery every 15 minutes, then over a span of one day, 96 deadlocked threads will have been created but not terminated ... 10 days == 960 threads, etc. etc. This is why I think I need to add the ability for the agent to disable a misbehaving discovery component. Something like, "if a discovery component times out N times, it should be disabled and never invoked again". Thoughts?