Equipment Browser Results

[DCIM_Support]

We have found a problem with our equipment browser. Using a combination of a search parameter in the main bar AND a sub filter brings up inconsistent results.

The issue seems to be related to a recent change we effected in the navigation tree/heirarchy. Is there a cache that needs clearing?

**************

Example 1:

Asset number 123456 (in the search bar)

Shows one entry in the list below with an incorrect location (old location with two levels missing) (greyed out as the room isn't yet loaded).

Upon loading the asset (via right hand click 'show in layout') it shows it in the layout windows and then refreshes the list view (in the equipment browser) with the correct navigation heirarchy tree (all the heirarchy levels) , - now in black as the room is loaded.

Example 2:

part of asset name entered to catch many devices (in the search bar)

shows many entries in the list below (greyed out as the rooms aren't yet loaded).

some entries are for historical locations that no longer exist? - But again when the containing rooms are loaded all is ok.

**************

So essentially, we appear to be seeing historical locations for devices in the equipment browser and the sub filter is not doing its job properly, - either showing old location references or none at all (without the room loaded). When the parent room is loaded all the errors dissapear.

I hope this makes sense - screengrabs are obviously difficult because of the asset details.

(CID:96764400)

[DCIM_Support]

Hi Nigel,

This is actually a refresh thing. So, once you change a location of the device or even delete the existing room, you need to change the perspective. It's a thick client based feature, you need to refresh the thing to get the change reflected in the Equipment Browser.

(CID:96764445)

[DCIM_Support]

thanks for this answer. Furthermore how do I : Refresh these DC rooms / change the perspective?

(CID:96764446)

[DCIM_Support]

Hi Nigel, You've mentioned that "The issue seems to be related to a recent change we effected in the navigation tree/heirarchy. " Can you please elaborate on the recent change(s), If possible consider a test with a clean cache, the client temporary files are usually on f.ex. (Win 7) C:\Users\\.isxo\7.4.xxx (the folder "7.4.xxx" can be renamed or deleted) Do you see a similar behavior/issue from another client/workstation? And/or other user(s) seeing the same issue?

(CID:96764471)

[DCIM_Support]

Hi Jeff, We added an additional folder in the heirarchy to represent the floor. Existing locations were dragged on to these new or renamed floors. I have backed up the folder described, deleted and restarted. The old historical locations are still visible though - for some assets not all - (as an attribute in an unloaded room). If we load the room the erroneous entries are replaced with the correct ones. By the way - other users are seeing the same issues with searches with the same parameters. Nigel

(CID:96764488)

[DCIM_Support]

Hi Nigel, Many thanks for the very interesting detail, Concerning "I have backed up the folder described (i), deleted (ii) and restarted (iii). " Do I understand correctly that you (i) saved the changes, (ii) deleted the "original and empty folders", and then saved the changes? (iii) restarted the client (or server)? "The old historical locations are still visible though - for some assets not all ..." Those assets, are they limited to a certain device type? (ex: pdu, server, blade, etc.) Would it be possible to ask for the following to be shared with me: 1. current backup file, 2. backup file before those changes 3. screen capture(s) to illustrate the issue 4. content of the following folder from server: /data/lucene 5. current log files, In DCO, logs are available in Help>Download Log Files. Note, that the download may take 5-10 minutes to complete. I can send you an invite to my Schneider box, if it is okay with you.

(CID:96764570)

[DCIM_Support]

Jeff, The cached folder actions were undertaken whilst DCO was stopped and then restarted. I didn't want to delete any folders whilst DCO was running, it sounded like bad practice but I can try this if you say it is safe to do so. The devices being returned with the old heirarchy are not limited to one type/model. Included are power supplies/servers/racks/crac units. What I meant by my comment was not every particular asset in a group of models (e.g. dl580's) were misrepresented by location. I can share backup file. I cannot share a file before the heirarchy changes (as it was longer than 30 days ago). Schneider might perhaps have another of ours from before then anyhow. I can take screen captures of the issue. The other info I will capture and put on your box share, please email details, thanks. Thanks

(CID:96764573)

[DCIM_Support]

Hi Nigel, Many thanks - please don't delete anything yet, I was just trying to follow the applied steps. I have send you an invite to my box, thanks.

(CID:96764577)

[DCIM_Support]

Hi Nigel, Many thanks for spending the time on collecting data and sharing with me, really appreciated. I'm currently working on the provided data and expecting to find some answers for you (soon), thanks.

(CID:96764739)

[DCIM_Support]

Hi Nigel

Thanks again for the provided data - the solution (both backups) seems to be fine, and the equipment browser (on my tests) displays the correct location info.

However, it seems the search indexes (from your cluster nodes) have not been updated and contain the records for the “old locations”.  Equipment Browser is using the search indexes (local to the server) to display the info on screen, and that’s why you are seeing those “old locations”.

Note: The search indexes are local to the server, and are not included in the backups.

It is not clear why the search indexes on your set-up have not been updated, but I will try to see if I can reproduce.

A workaround is to reset the indexes manually.

The following resolution is for each server in the cluster:

ssh log in to the server and then:

1. Run the command: "sudo service operations stop" in order to stop the JBoss server.
2. Run the command: "sudo rm -rf /data/lucene/indexes/" in order to remove the indexes
3. Run the command: "sudo service operations start" in order to start the JBoss and rebuild/update the indexes.

Wait until the Webmin shows the server running again (might take 20-30 min). Continue with the next server.

(CID:96764794)

[DCIM_Support]

Thanks Jef. Interesting findings. I cannot undertake the required changes until we can schedule a suitable window to do so. I will undertake the command scripts above though at the first opportunity which looks like this Friday morning 22nd GMT. When complete I will share my findings. Thank you.

(CID:96764807)

[DCIM_Support]

This question is closed for comments. You're welcome to start a new topic if you have further comments on this issue.