Bug 1100300 - Update of a resource configuration sometimes takes more then 100 seconds
Summary: Update of a resource configuration sometimes takes more then 100 seconds
Alias: None
Product: RHQ Project
Classification: Other
Component: Configuration
Version: 4.11
Hardware: Unspecified
OS: Unspecified
high vote
Target Milestone: GA
: RHQ 4.12
Assignee: Jay Shaughnessy
QA Contact: Mike Foley
Depends On:
TreeView+ depends on / blocked
Reported: 2014-05-22 13:09 UTC by Filip Brychta
Modified: 2014-12-15 11:36 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2014-12-15 11:36:35 UTC

Attachments (Terms of Use)

Description Filip Brychta 2014-05-22 13:09:39 UTC
Description of problem:
This issue was reported by automation. It's not easy to reproduce it locally.
So far it happened during configuration update of following resource types:
[as7] Security Domain
[as7] Security
JBossAS7 Standalone Server
and some more, so it seems it's not tied with specific resources but it's general problem.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. navigate to some resource listed above 
2. and try to update it's configuration

Actual results:
It takes up to 100 seconds to update the configuration (Configure_inprogress_16.png is visible).

Expected results:
It should take a few seconds.

Additional info:
This is not related to HA (it happens with single server as well)
No exceptions in logs.

Comment 1 Libor Zoubek 2014-05-22 20:03:38 UTC
I was hitting this issue as well. There is a scheduled job on agent ConfigurationCheckExecutor, that collects configurations for all resources. This job is implemented as Runnable. Then there is a ThreadPool with size 1 thread, that handles above job + whenever there comes request from server it's also executed in this threadpool. 

So .. when this job is running, it's actively blocking config update request from server to happen.

This issue is visible since 4.10, when there has been added waiting 750ms to scheduled job, whenever it loads config for 1 resource. This job can then run for example 10minutes if you have enough resources.

I talked to Heiko .. and there's an intention of having only 1 thread (to avoid concurrency issues .. interference of scheduled job and "manual" config updates.

Possible solution would be to change scheduled job not to be single runnable, but rather a queue of runnables, that would be executed one after each other, and have priority queue so we can insert config update request to the beginning of queue to make sure it gets executed almost immediatelly.

Comment 2 Jay Shaughnessy 2014-06-25 20:22:58 UTC
Update: Work is progressing in https://github.com/rhq-project/rhq/pull/62

It's hopefully close to a merge.

Comment 3 Jay Shaughnessy 2014-06-26 20:45:46 UTC
master commit 03c2e260be2d7e92c95f6b2302e6bcba163c0797
Merge: d2427f0 a0922b4
Author: jshaughn <jshaughn@redhat.com>
Date:   Thu Jun 26 16:38:53 2014 -0400

    Merge pull request #62 from rhq-project/jshaughn/1100300

Comment 4 Filip Brychta 2014-07-03 13:55:14 UTC
Verified on
Version :	
Build Number :	

Comment 5 Heiko W. Rupp 2014-12-15 11:36:35 UTC
Bulk close of items fixed in RHQ 4.12

If you think this is not solved, then please open a *new* BZ and link to this one.

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