[MAGNOLIA-1263] links are sometimes resolved wrongly after a move of a page (session is not updated) Created: 08/Dec/06  Updated: 23/Jan/13  Resolved: 06/Nov/07

Status: Closed
Project: Magnolia
Component/s: templating
Affects Version/s: 3.0.1
Fix Version/s: 3.5 RC1

Type: Bug Priority: Critical
Reporter: Philipp Bärfuss Assignee: Philipp Bärfuss
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File jcr-session-status.jsp    
Issue Links:
dependency
depends upon MAGNOLIA-1225 HierarchyManager - inconsistency in u... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

This dosn't happen regularely, but it can happen that after a move of a page the link is still pointing to the old place. This is obviousely a session updating problem and needs some investigation. In case this happens a restart of the container heals the system. In case you can't do this you can copy the page instead of moving (ugly but working)



 Comments   
Comment by Chris Allan [ 08/Dec/06 ]

Just to clarify, to those that it does happen to, it does happen regularly. It is 100% guaranteed to happen!!!

Comment by Chris Allan [ 08/Dec/06 ]

And just to further clarify, the problem does not only apply to existing links not getting updated. If, following the moving of a page, you try and create a link to it, the new link will point to the old page location.

Comment by Chris Allan [ 08/Dec/06 ]

Hmm, on second thoughts maybe my first 'clarifying' wasn't perfectly clear. When I said 'those' that it happens to I mean those people that it happens to, not those pages i.e. it does happen to me, and it does happen with every single page that is ever moved.

Comment by Philipp Bracher [ 08/Dec/06 ]

Does closing and reopening the browser help?

Comment by Chris Allan [ 08/Dec/06 ]

Not in the slightest, neither does clearing out all the cache or any other files.

Comment by Philipp Bracher [ 08/Dec/06 ]

This implies that the system session is not updated.

Thanks for the information.

Comment by Philipp Bracher [ 15/Dec/06 ]

Can you execute this page, after the problem occures.

put the file in the docroot and call it directly

Comment by Philipp Bracher [ 09/Feb/07 ]

Some more news about this issue. I run into the same situation and was able to debug a bit. The situation occured after:

  • copy a page (/ch/fr/news/halsschmerzen)
  • rename the page (/ch/fr/news/maux-de-gorge)
    --> all links pointing to the name before the renaming (halsschmerzen)

In the text the correct link tag was saved (maux-de-gorge)

<a href="${link:{uuid:

{311af940-...}

,repository:

{website}

,workspace:

{default}

,path:

{/ch/fr/news/maux-de-gorge}

}}">

the uuid is correct and the fall pack path too (maux-de-gorge)

Since for saving the user session is used, this is not a surprise.

Then I run the attached jsp to check if there were any pending changes: No there weren't
Then I run a jsp to refresh the system session: Didn't help

Now I created the following code:

Content node = MgnlContext.getSystemContext().getHierarchyManager(repository).getContentByUUID("311af940...");
out.println(node.getHandle());

node.getParent().refresh(false);
out.println(node.getHandle());

node = MgnlContext.getHierarchyManager(repository).getContentByUUID("311af940...");
out.println(node.getHandle());

The result was:

/ch/fr/news/halsschmerzen
/ch/fr/news/halsschmerzen
/ch/fr/news/maux-de-gorge

So we can finally say that:

  • System session is not updated
  • refresh of the system session does not help

Conclusion

  • Unless this jackrabbit bug is not fixed we can't do anything against it
  • Perhaps it is not a good idea to keep the system session that long (for ever in fact)

Hint:

  • the renaming does a move on the workspace instead in the user session, perhaps this conflicts with updating the system session.
Comment by Philipp Bracher [ 06/Nov/07 ]

we had no such experiences anymore with jr 1.3

Generated at Mon Feb 12 03:25:14 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.