[
https://issues.apache.org/jira/browse/JCR-4954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784768#comment-17784768
]
Manfred Baedke edited comment on JCR-4954 at 11/10/23 10:51 AM:
----------------------------------------------------------------
Hi [~c_koell] ,
Thx for the effort!
??I hope you will understand the problem now ;)??
Well, at least one of us doesn't fully understand the problem yet. Maybe it's
just me, but it might also be both of us :)
Let me elaborate:
??For me it's not clear how to fix the problem but I think Server B should
return on PROPFIND lockDiscovery the same LockToken as created on LOCK
Operation.??
Yes, of course, the problem is that it returns the lock with a session scope
prefix (4403ef44-4124-11e1-b965-00059a3c7a00) instead of an open scope prefix
(dccce564-412e-11e1-b969-00059a3c7a00). So the question is: Why does it do that?
Now take a look at
[https://github.com/apache/jackrabbit/blob/90b60f4561eae41256c2110df3a72b854ead962d/jackrabbit-jcr2spi/src/main/java/org/apache/jackrabbit/jcr2spi/lock/LockManagerImpl.java#L675.]
As you can see, when a LockImpl object is created with an open scope, an
internal flag is set to reload the LockInfo. This will be done if and only if
the method LockImpl.updateLockInfo() is called. AFAICS {*}this operation will
transfer the lock to the new session{*}. So we have to make sure that it
actually gets called and one of the ways to do that is calling
lock.getLockToken(), which the patch does, but maybe not in the right place, or
the analysis is incomplete. To verify that, you could check if on lock
discovery, the reloadInfo flag in the constructor of LockImpl is actually set
and the method LockImpl.updateLockInfo() is not called, in which case this
general idea would be correct.
was (Author: baedke):
Hi [~c_koell] ,
Thx for the effort!
??I hope you will understand the problem now ;)??
Well, at least one of us doesn't fully understand the problem yet. Maybe it's
just me, but I'm not sure :)
Let me elaborate:
??For me it's not clear how to fix the problem but I think Server B should
return on PROPFIND lockDiscovery the same LockToken as created on LOCK
Operation.??
Yes, of course, the problem is that it returns the lock with a session scope
prefix (4403ef44-4124-11e1-b965-00059a3c7a00) instead of an open scope prefix
(dccce564-412e-11e1-b969-00059a3c7a00). So the question is: Why does it do that?
Now take a look at
[https://github.com/apache/jackrabbit/blob/90b60f4561eae41256c2110df3a72b854ead962d/jackrabbit-jcr2spi/src/main/java/org/apache/jackrabbit/jcr2spi/lock/LockManagerImpl.java#L675.]
As you can see, when a LockImpl object is created with an open scope, an
internal flag is set to reload the LockInfo. This will be done if and only if
the method LockImpl.updateLockInfo() is called. AFAICS {*}this operation will
transfer the lock to the new session{*}. So we have to make sure that it
actually gets called and one of the ways to do that is calling
lock.getLockToken(), which the patch does, but maybe not in the right place, or
the analysis is incomplete. To verify that, you could check if on lock
discovery, the reloadInfo flag in the constructor of LockImpl is actually set
and the method LockImpl.updateLockInfo() is not called, in which case this
general idea would be correct.
> Problem with WebDav Client and Repository Server Deployment Model
> -----------------------------------------------------------------
>
> Key: JCR-4954
> URL: https://issues.apache.org/jira/browse/JCR-4954
> Project: Jackrabbit Content Repository
> Issue Type: Bug
> Components: jackrabbit-jcr-server, jackrabbit-webdav
> Reporter: Claus Köll
> Assignee: Manfred Baedke
> Priority: Major
> Fix For: 2.22
>
> Attachments: Call-Hierarchy.txt, JcrRemotingServlet.txt,
> JcrRemotingServlet_2.txt, SimpleWebDavServlet.txt, SimpleWebDavServlet_2.txt,
> config.xml, jcr-4954-diagnose.patch
>
>
> We have one WebApp where we have deployed the SimpleWebDavServlet
> (WebDav-WebApp). From there we connect to a other WebApp where we have
> exposed a Repository through DavEx
> (org.apache.jackrabbit.server.remoting.davex.JcrRemotingServlet)
> and also the RMI-Layer by the RMI Registry (Repository-WebApp)
> Until now we connected over RMI but now we tried to switch to DavEx. The
> Problem is, that we are now unable to unlock a opened WebDav Document.
> The Lock Request in the Repository-WebApp adds a Reference (LockToken) to the
> DavSession so a future Requests can obtain the same DavSession to perform the
> unlock.
> https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/webdav/jcr/DefaultItemCollection.java#L700
> The Reference (Locktoken) looks like
> opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4-0
> It will be generated by the LockTokenMapper
> https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/webdav/jcr/lock/LockTokenMapper.java#L53
> In the WebDav-WebApp the HeaderLockToken will be stored in this format
> opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00:opaquelocktoken%3a4403ef44-4124-11e1-b965-00059a3c7a00%3a0089610c-02e5-43cd-bfec-3a90361350f4
> As you can see it will be double wrapped. That's not really a Problem because
> on unlock the WebDav-WebApp removes the prefix
> opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00:
> Finally this locktoken will be send from the WebDav-App to the
> Repository-WebApp
> opaquelocktoken:4403ef44-4124-11e1-b965-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4
> On the Repository-WebApp the JCRWebdavServer will look for a DavSession in
> the Cache based on the lockToken
> https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-jcr-server/src/main/java/org/apache/jackrabbit/server/jcr/JCRWebdavServer.java#L210
> So the problem is that the DavSession whitch have created the Lock, is stored
> with a lockToken that do not match with the incoming lockToken
> Cache-Key-Token:
> opaquelocktoken:dccce564-412e-11e1-b969-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4-0
> Incoming-Token:
> opaquelocktoken:4403ef44-4124-11e1-b965-00059a3c7a00:0089610c-02e5-43cd-bfec-3a90361350f4
> The DavSession-Cache Key is taken from the LockInfo (LockTokenCheckDigit is
> present)
> https://github.com/apache/jackrabbit/blob/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/lock/LockInfo.java#L118
> Maybe someone which is familiar with the code of LockTokenMapper can explain
> the two different Scopes (SESSIONSCOPED/OPENSCOPED)
> One possible solution could be to change the code in the LockTokenMapper to
> always return the Node Identifier with the same SCOPE-PREFIX?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
