Lingering node references

[petern]

Hi all,
We have been developing a document repository using Alfresco and have come across two weird 'phantom node reference' issues. I would be grateful if anyone could shed some light no the matter or point out what it is that we've just totally overlooked in either case.

Firstly:
We have developed a custom action which is responsible for 'intelligently' moving or merging directories from one location in the repository ('inbox') to another location ('document store'). The specific logic isn't important, suffice to say that it will either
- Move the entire folder "Inbox > Foo" to "Document Store > Foo" if the latter does not exist.
- Move the *contents* of "Inbox > Foo" if "Document Store > Foo" does exist, which consists of moving all of the files from one to the other, renaming as necessary to avoid overwrites, leaving an empty folder "Inbox > Foo" which is then deleted.

The action can either be performed via the "Run Action" wizard, or by an inline link which shows up by folders in Space Browse view, along with Cut, Copy, Edit offline, etc. The action is a Java class extending ActionExecutorAbstractBase, with an evaluator and a bean class. It is registered as a managed bean so that the action links can call it, and the action links are configured and working.

If the action is performed by clicking the inline-link, you're returned to the space containing the node you actioned when the action finishes (that is to say, if you're at "Inbox" and you click the action link on node "Foo", the action runs and you are returned to "Inbox").

We have come across an issue whereby *sometimes*, in the case where the node is moved as opposed to deleted, we are returned to Inbox and our "Foo" node, which should have either been whisked off elsewhere, is still visible - thus making it theoretically possible to run the action again, as well as being a bit confusing for users. If we re-load the page the problem is solved. Other times this does not happen and the node is gone right away, as you would expect. The node (and all its children) are successfully moved to their destination in either case, and this leads me to believe it is an issue whereby the internal references Alfresco is using to generate the 'browse' page upon completion of the action are out of date. Finally, if the 'ghost' item's name is clicked we successfully navigate to it, albeit we are actually navigating to 'Document Store > Foo'
The wiki states:

By default, each invocation of a Service method is wrapped in its own transaction. This has been configured via Spring

Which I have not changed. This means I do not need to transact my actions as a whole either?

Secondly:
We are using the CIFS server, with a mapped network drive on a windows box pointed at the 'Inbox' folder. If we create a directory 'Foo' therein, everything is well and we can populate the dir with files, delete, etc.
However, if we remove that folder from within the web interface (cut/paste elsewhere, or delete) we run into more lingering-reference issues (removing the folder via CIFS works fine). Moving the folder from 'Inbox > Foo' to 'Somewhere > Foo' via the web interface (e.g. via the custom action above) does everything as expected as far as the webclient is concerned - looking in Inbox reveals no Foo folder (unless of course the above issue occurs too!). If we refresh the Explorer window pointing to the CIFS dir, then the folder will disappear from here too. However, it is still 'there'. Dragging or creating another folder with the same name in CIFS will create a folder point to wherever the other was moved to. This is a problem as it is possible a same-named folder could be require to be created often, and it is crucial that our actions/processing are not bypassed.
The first issue could feasibly by our fault, but the second one I'm not so sure about - it's reproducible using stock Alfresco actions, most notably delete.
Restarting Tomcat will clear the issue up - no ghost references in CIFS afterwards.

Any ideas? Is it just Alfresco being weird or are we doing something wrong?

Best,
Peter.

[kumbach]

I don't have an answer for you, but thought that I'd mention something I ran across as it sounds suspiciously similar to what you're seeing…

We had a webscript that ran every minute via the Quartz scheduler inside Alfresco. It's job was to watch for documents that arrive in a space named "Inbox". When something new arrived, the script would simply move the document into another space based on some business logic.

We wanted to implement the Inbox idea to avoid having to give users add permission on all the spaces in the repository. We have 80,000+ spaces and setting permission on all those spaces was something we wanted to avoid. 

The Inbox webscript used a Lucene query to find new Inbox documents. What would occasionally happen was that after a document had arrived in the Inbox, and was moved to a new space, the Lucene query would later report that the document is still in the Inbox. When trying to refile the document again, the script broke because the document doesn't really exist in the Inbox and all kinds of errors then occurred. 

As a side affect, the Alfresco GUI also showed the problem document as still being in the Inbox. However, when using the Node Browser to navigate to space where the document should be, it appears to have been refiled correctly.

I suspect this is an Alfresco indexing bug but haven't been able to prove it.

We eventually gave up on the Inbox idea and resorted to setting permissions on all the 80,000 spaces and then allowed users to save document directly in the other spaces.

Anyway, I hope this info is useful to you and maybe to other people as well.

[petern]

Hi, thanks. At least it somewhat confirms that the problem exists - it does sound similar.

Interestingly, node collections available to and hence file lists generated by templates and webscripts seem to be immune. Try creating a simple template which lists a folder's contents and see if moved nodes show up there? It would be interesting to see if that works for you too. Unfortunately it doesn't yet seem to be possible to link to an action in a webscript, otherwise this problem could be entirely worked around using the webscriptable aspect.

As there seems to be no quick way around this, my solution in the end was to modify the evaluator for my action's links so that it would, from the node under scrutiny, work up the node hierarchy from each node and at each level test if this is the 'Document Store' node then fail if this was the case. Somewhat slow, but it prevented data loss.

How did you manage to set the permissions on all those spaces - presumably programmatically!

[kumbach]

We've implemented our own front-end to Alfresco so we don't use templates, actions, etc. Thank goodness for that because I find each of these features in Alfresco (and others too) has some quirk or bug that always seems to mess us up.

Yes permissions are set using a program, that's just way too many spaces to maintain any other way…