Bug 535268 - (RHQ-1982) Lower default service scan interval from the current 24h
Lower default service scan interval from the current 24h
Status: CLOSED NOTABUG
Product: RHQ Project
Classification: Other
Component: Agent (Show other bugs)
unspecified
All All
low Severity medium (vote)
: ---
: ---
Assigned To: RHQ Project Maintainer
http://jira.rhq-project.org/browse/RH...
: Improvement
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-16 10:31 EDT by Heiko W. Rupp
Modified: 2010-08-05 13:39 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-08-05 13:39:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Heiko W. Rupp 2009-04-16 10:31:00 EDT
See http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4225938#4225938

I have seen a few comments now, where people add some stuff manually and are negatively impressed when it does not show up in the UI.

We should lower the service scan interval to something like 1h. This should be a good tradeoff between load on the target resources and the convenience for the user.
Comment 1 John Mazzitelli 2009-04-16 10:53:49 EDT
I already do not like the fact that we are probing all resources for their configs every 1h.  Now we are going to do that AND probe the resources for new services every 1h?  To me, we are adding too much load on the managed resource too often.

From a new customer's perspective, I don't see how 1h helps them, over the 24h. Its still a "long delay" from their perspective - and I'm sure we'll get comments, "its taking one hour for my new war that I just manually deployed to show up in the UI, how do I make it go faster".

I suggest we leave it as-is and let users configure it themselves if they want it faster.
Comment 2 John Mazzitelli 2009-04-16 10:55:06 EDT
do not fix for 1.2 - too late in the release cycle to make this large of a change - it will affect performance.
Comment 3 Charles Crouch 2009-04-16 11:49:27 EDT
"From a new customer's perspective, I don't see how 1h helps them, over the 24h. Its still a "long delay" from their perspective - and I'm sure we'll get comments, "its taking one hour for my new war that I just manually deployed to show up in the UI, how do I make it go faster".

I suggest we leave it as-is and let users configure it themselves if they want it faster."

Totally agree.
The difference between "instantaneous vs. 1hr"  and "instantaneous vs. 24hrs" is not significant from a usability perspective IMHO, a 1hr delay is still not what the customer expects.
Comment 4 Red Hat Bugzilla 2009-11-10 15:55:25 EST
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-1982
Comment 5 Corey Welton 2010-08-05 13:39:56 EDT
Mass closure per triage.   If you consider this a critical issue, the bug may be reopened later for future consideration.

Note You need to log in before you can comment on or make changes to this bug.