[MNT-1765] Space visible in tree (and node browser) but not in parent space Created: 26-Mar-09  Updated: 19-Mar-13  Resolved: 04-May-10

Status: Closed
Project: Service Packs and Hot Fixes
Component/s: Repository
Affects Version/s: 2.2.3
Fix Version/s: 2.2.8

Type: Service Pack Request
Reporter: Andrew Hunt [X] (Inactive) Assignee: Closed Issues
Resolution: Cannot Reproduce Votes: 3
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File ESIS_Space_not_visible.png    
Issue Links:
Related
is related to by MNT-7744 2.2 SP8 retests Closed
Bug Priority:
Category 1
ACT Numbers:

7840


 Description   

A symptom of this problem is that it is possible to see a space in the Navigator pane, but that space does not appear in the main panel of the web client.

Renaming and/or copying the parent space of the affected content remedies the problem, but a FULL re-index alone does not.

The issue is intermittent and it is not reproducible at will, but is possibly connected to the load on the system at the time of the original upload of the content.

After discussions with AndyH, I believe that the cause is somewhat understood.



 Comments   
Comment by Andrew Hunt [X] (Inactive) [ 30-Apr-09 ]

Screenshot of problem on customer's system

Comment by Andrew Hunt [X] (Inactive) [ 30-Apr-09 ]

All the node information is correctly stored - e.g. parent-child relationship etc. - as can be seen through the node browser.
The Navigator pane shows all the spaces correctly.
The main panel does not show the space.

The only thing that seems not to be correct is the indexing of the content. It's as though the affected spaces are simply missed out of the indexing process - but apparently it is more the case that it is indexed out of turn (as I understand it).

Comment by Andrew Hunt [X] (Inactive) [ 23-Feb-10 ]

All the folders are of the standard cm:folder type.

As mentioned above, touching a property on the folder causes the problem to go away, as the folder gets re-indexed.

It is the indexing of the folder that is at fault, not the method of retrieving the data from the index

Comment by Andrew Hunt [X] (Inactive) [ 01-Mar-10 ]

Hi Mike,
I wasn't saying that re-indexing alone helps. However, if you 'touch' a folder, it creates a new transaction, and it is this new transaction that then gets indexed properly.

To answer your questions:

  • Yes, the content can be found by searching. However - the path that is returned for the document is all wrong.
    E.g. Search: PATH:"app:company_home/app:guest_home/cm:ESIS/cm:Color"
    result: Name: {http://www.alfresco.org/model/content/1.0}

    Color;/{}member;/{}member;/{}member;/{}member;/{}member

  • A few hundred thousand files in tens of thousands of folders, if I remember correctly.
  • Content is all sorts of mimetypes. Pdfs, html, txt
  • The only import-related thing that seems to affect the problem is the uploading of lots of folders/documents at the same time.
Comment by Andrew Hunt [X] (Inactive) [ 04-May-10 ]

Unfortunately, this is not possible, for two reasons:

1) The affected folders do not get exported

2) The customer has a workaround (automatically touching the affected folders every night), and (understandably) does not want to deliberately cause a problem on the system after a year of it running smoothly.

Comment by Dave Ward [X] (Inactive) [ 04-May-10 ]

We are unable to reproduce this issue internally and are not able to get any more information from the customer that will help us reproduce it.

Comment by Alfresco QA Team (Inactive) [ 03-Jun-10 ]

Cannot reproduce in Alfresco 3.2 EE build 554 using Windows 2008 SP1 x64, Tomcat 6.0.18, Mysql 5.1.34, JDK 6u20 x64.

Generated at Sun Mar 07 18:45:22 GMT 2021 using Jira 7.13.15#713015-sha1:7c5ddd2c3e1709974ae9c48c17df8edd3919fe2c.