-
Improvement
-
Resolution: Done
-
Neutral
-
None
-
1.2.1
-
None
-
-
Empty show more show less
-
Yes
-
HL & LD 22, HL & LD 23, HL & LD 24
-
8
Since the introduction of the publishing modules we have seen some tickets coming through support where customers are unable to publish due to "locked nodes". It seems that we have two different kinds of locks.
- The actual JCR lock that is applied to nodes when performing the activation.
2020-08-21 11:20:22,923 DEBUG ional.receiver.locking.TransactionalJcrLockManager: About to begin publish of website:8fa4a73f-51c3-40ac-b698-715595216186:/travel/about/company 2020-08-21 11:20:22,923 DEBUG ional.receiver.locking.TransactionalJcrLockManager: 376:1598001622918 Requesting XA lock 2020-08-21 11:20:22,931 DEBUG info.magnolia.publishing.locking.JcrLockManager : parent path:/travel/about/careers 2020-08-21 11:20:23,007 DEBUG info.magnolia.publishing.locking.JcrLockManager : session-admin-256 DID locked website:/travel/about/careers
- Also a temporary node in the mgnl-system workspace that is acting as "lock" and being reported as such.
It would be helpful to distinguish in the logs (both author and public) which kind of lock we are dealing with. One issue is an actual locked node where the other is more of a flag.
An improvement would be a way to clear these issues from the Publishing app. Right now I have statistics about publishing data and can see that errors have occurred (if any). But I have no way to take any action on those errors. With a lock management app I would have a way to inspect the current locks and a way to release them.
- is related to
-
EEPUBLISH-28 Recurring Problem With Node Locking After Publishing is Causing Closed Sessions
- Closed
-
PUBLISHING-99 Move away from JCR node locking
- Closed
-
PUBLISHING-88 Keep track of lock owners with session data
- Closed
-
MGNLSYNC-42 Synchronization manager does not complete normally
- Closed
- links to