Created attachment 564907 [details] 2nd imported EAP with undefined children availability Version-Release number of selected component (if applicable): Version: 3.0.1.GA Build Number: dd8a001:fbca611 EAP 5.1.2 How reproducible:always Steps to Reproduce: 1. have 2 unsecured EAP5 instances running on same host (use -Djboss.service.binding.set=ports-01 for the 2nd one to shift ports) 2. start agent 3. go to discovery queue and import both servers at the same time Actual results: both servers get imported but one of them has all children being down, more precisely they have undefined availability (?) see screenshot. Expected results: Both servers are properly inventoried like if you'd inventory them one after each other. Additional info: There is a simple workaround. Just uninventory that badly detected one and inventory it again.
triage 2/27/2012 mfoley, asantos, crouch, loleary
This seems very odd. I have imported multiple EAP instances on many occasions in previous versions of JON/RHQ. The most common issue I have seen in this regard is that if the UI refreshes during the service discovery/import and the availability check, it is possible the availability will display as unknown until the next avail check is performed. Which would also require a UI refresh after the next avail executes. Can you verify that this is not the case and that enough time had elapsed between the import of the servers and the refresh of the UI? Debug logs from the agent may prove helpful here too.
It is the case. After importing both servers I've observed agent's debug log and waited 'till it was calm. Then checked servers in the UI and both were imported/detected correctly.
re-opening ... i misinterpreted comment #3 to mean NOTABUG but that was a misread of comment #3.
#3 was confirmation of Larry's suspects, which I think is a bug.
Not sure I would classify this as a bug. Everything is working as designed. However, this confusion is common. The problem is, it isn't an easy thing to fix based on the current implementation. A similar confusion is already identified in Bug 743727. Basically, the UI does not provide any information to the user as to the actual state of the inventory and what is going on under the covers. In this case, the fact that discovery has not finished executing for one of the servers in question resulting in an UNKNOWN availability. Keep in mind that this is a UI issue really. At the time the UI asks for this information, it is unavailable. The user is expected to refresh the page until they are satisfied that the resource is really unavailable (5 seconds, 1 minutes, 10 minutes, how long is long enough?) Perhaps RHQ 4.2 fixes this with the new GWT UI? If this type of data could be fed to the UI as it becomes available, it would reduce the confusion.
Hmm .. I see 2 issues here. First one is about the confusion. At the time when discovery is running, user can see both servers as down, I was able to observe how children resources are missing at all and they appear after pushing 'Refresh' button, they were off, but after a few seconds, they become available as expceted. Yes, user can ask "Why the hell is this offline?" then he tries refreshing and figures out, that resources were being imported. Second one is bigger issue. This BZ was meant to be about it. If all conditions are met to reproduce this issue, 2nd server remains unavailable no matter how many times user refreshes UI, the only way to see resource in correct state is to wait for next availability report
I think this is solved by Bug PM-403 ?
Well, partially. PM-403 takes care of what comment 7 mentions in its first paragraph. However, the second paragraph of comment 7 doesn't seem to be handled by PM-403. From the description and what is restarted in comment 7, the issue is that if you import two EAP servers running on the same host the first one is reported as UP while the second one continues to be reported as DOWN no matter how long you wait. I have never seen this or had a similar issue reported. Also, this was originally discovered on JBoss ON 3.0 so perhaps this has since been addressed?
let me try to reproduce it on RHQ 4.9
I can no longer observe this issue on RHQ 4.9, closing as notabug