Bug 818522 - [eap6] new child resource is not discovered immediately
Summary: [eap6] new child resource is not discovered immediately
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: RHQ Project
Classification: Other
Component: Agent
Version: 4.4
Hardware: Unspecified
OS: Unspecified
high
urgent
Target Milestone: ---
: RHQ 4.5.0
Assignee: Charles Crouch
QA Contact: Mike Foley
URL:
Whiteboard:
Depends On:
Blocks: as7-plugin
TreeView+ depends on / blocked
 
Reported: 2012-05-03 09:10 UTC by Libor Zoubek
Modified: 2015-11-02 00:42 UTC (History)
5 users (show)

Fixed In Version: 4.5
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 825029 (view as bug list)
Environment:
Last Closed: 2013-09-01 10:13:12 UTC
Embargoed:


Attachments (Terms of Use)
agent.log (8.56 KB, application/octet-stream)
2012-05-03 09:10 UTC, Libor Zoubek
no flags Details

Description Libor Zoubek 2012-05-03 09:10:02 UTC
Created attachment 581809 [details]
agent.log

Description of problem: I am experiencing very slow discovery of new child resources. Once I add a child resource, I can almost immediately detect it via EAP CLI, but sometimes it takes up to 10 minutes 'until it is discovered by agent.


This applies to creating new web connector, JMS topic/queue for example.

Version-Release number of selected component (if applicable):
Version: 4.4.0-SNAPSHOT
Build Number: 2484565
EAP6 ER6

How reproducible:mostly on some resources/not sure


Steps to Reproduce:
1. Import EAP6 standalone, create web connector for example
2. keep refreshing inventory 'till connector appears
  
Actual results: it takes up to 10 minutes, there are some suspects in agent.log, see attachment


Expected results: resource gets discovered immediately 


Additional info: If you cannot reproduce, try adding/removing resource a few times.

Comment 1 Heiko W. Rupp 2012-05-08 19:20:45 UTC
Without the additional info I can't reproduce.

I think this is some plugin-container related, that should also show up on as4/5

Comment 2 Heiko W. Rupp 2012-05-08 19:38:54 UTC
Can you create better reproduction steps and also try the very same steps on other kinds of resources?

Comment 3 Charles Crouch 2012-05-08 19:47:55 UTC
Dropping priority to high, since we've not been able to reproduce it

Comment 4 Libor Zoubek 2012-05-11 13:21:14 UTC
The bug is still here. I've just reproduced it on JON 3.1.CR1. Steps to reproduce are same:

1. have standalone running (this time it was in ha mode)
2. created WAR deployment child
3. it took 3 minutes and deployment resource was still not present in UI, so I've started manual discover which found the resource.

Maybe it is only discovery is too slow and there is a relation to Bug 820709

Comment 5 Ian Springer 2012-05-17 02:08:00 UTC
The issue here is most likely that a service discovery scan was in progress when you initiated the WAR create resource requests. In that case, the plugin container would have to wait for that scan to complete before initiating a new scan for the purpose of discovering the newly added WAR. This is because all discovery scans are executed in a single thread in the plugin container (i.e. only one discovery scan can execute at any given time - any others are queued up).

That being said, I admit having to wait several minutes for the WAR to show up in your inventory is non-intuitive and inconvenient. To ease the pain a bit, I've made two small improvements:

1) When you initiate the create request via the GUI, the following green status message is now displayed at the top of the GUI:

  A request to create a Resource of type [{0}] has been submitted successfully. Note, it may take several minutes for the Resource to show up in inventory.

2) Once the service scan that is supposed to discover the newly added WAR finally completes, the PC now checks if the Resource actually got discovered. If it did, the following message is written to the Agent log:

  INFO: Discovered Resource[id=xxxxx, ...], for a new managed resource created via RHQ.

And if it was not discovered, the following message is logged:

  WARN: Failed to discover Resource for newly created [Deployment] managed resource with key [foo.war].


[master http://git.fedorahosted.org/git?p=rhq/rhq.git;a=commitdiff;h=8ef472f]

Comment 7 Heiko W. Rupp 2013-09-01 10:13:12 UTC
Bulk closing of items that are on_qa and in old RHQ releases, which are out for a long time and where the issue has not been re-opened since.


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