Bug 586027 - Wrong InfoBlock message when sync selected Repositories with no content.
Summary: Wrong InfoBlock message when sync selected Repositories with no content.
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: RHQ Project
Classification: Other
Component: Content
Version: 1.4
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Simeon Pinder
QA Contact: Corey Welton
URL:
Whiteboard:
Depends On:
Blocks: jon24-content
TreeView+ depends on / blocked
 
Reported: 2010-04-26 16:28 UTC by John Sefler
Modified: 2010-05-21 15:46 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-05-21 15:46:32 UTC
Embargoed:


Attachments (Terms of Use)

Description John Sefler 2010-04-26 16:28:26 UTC
Description of problem:
During this IManage/JON24 development cycle, Content Sources were renamed to Content Providers and later reverted back.  During the revert, one of the corrected behaviors was lost in the revert.  Please bring it back, its blocking an automated test....
When selecting repositories to sync that actually contain no content, the InfoBlock message used to correctly say "Selected Repositories have no content to sync." and now it incorrectly states "Synchronizing [1] content sources." when the selected repository actually has no content.


Version-Release number of selected component (if applicable):
 RHQ
version: 3.0.0-SNAPSHOT
build number: 4fd30d0 

How reproducible:


Steps to Reproduce:
1. Create a new Repository...   Administration > Content > Repositories
2. check the new repository and click SYNC SELECTED
  
Actual results:
Synchronizing [1] content sources. 

Expected results:
Selected Repositories have no content to sync.

Comment 1 Simeon Pinder 2010-05-05 20:23:49 UTC
This is not just a matter of adding the message information back.  Due to the code changes that have been made, the method no longer has access to real time data about whether the N synchronized messages actually had any content to display.  It looks like the previous synchronous nature was causing delays in the UI under load. 

The mechanism was changed to be asynchronous in nature so that complete synchronization occurs in a scheduled operation.

The short of it is that the we no longer provide that type(completed and how) of messaging in the top level 'Content Sources' synchronize gui action to the client.  

How is the test being blocked by no longer having this information? 

You should still be able to get this information by browsing the "Synchronization Results History" for the specific Content Source that the synchronization was being run on.  You will likely need to monitor the status to of the most recent Synchronization run for "Successful" or "IN PROGRESS" and then view the results.  That part could probably be achieved by a CLI script.

One more note: viewing the results of a synchronization is affected by BZ 589199.

Comment 2 John Sefler 2010-05-06 14:16:38 UTC
 RHQ
version: 3.0.0-SNAPSHOT
build number: b338c7f 

When a Repository has NO associated content source and it is selected for synchronization.  The resulting Synchronization Status is SUCCESS and the Synchronization Results are:

Thu May 06 09:54:32 EDT 2010: Start synchronization of Repository [foo]
Thu May 06 09:54:32 EDT 2010: Getting currently known list of content source packages...

Thu May 06 09:54:32 EDT 2010: Repository [foo] completed syncing with no errors.


I would have expected the results to say something to the effect that "Selected Repositories have no content to sync." as it used to say in an earlier version of IManage.

Comment 3 Simeon Pinder 2010-05-10 16:05:32 UTC
Before we would i) launch the synchronization and ii)the wait for the results in the UI thread before iii) displaying those results back.  

Since we've moved steps ii and iii into it's own thread, then the only information we can offer back to the user immediately is that N synchronization requests have been started and whether there was a problem trying to schedule them.  Meaning that regardless of results for each content source, the operation was requested/initialized successfully.  

It's usually a good practice to not include potentially process intensive operations in the initial user response.  To properly monitor the status of the synchronization request, the user will need to look at the "Synchronization History" for the specific 'Content Source' and monitor the entries appropriately. This pattern is used successfully other places in the RHQ UI.

Comment 4 Corey Welton 2010-05-21 15:46:32 UTC
QA Closing - we can reopen later if necessary.


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