You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Lukas Kahwe Smith <ml...@pooteeweet.org> on 2012/02/10 09:24:03 UTC

LockManagerImpl.java:813 Bad lock token: Bad check digit. Token [..]

Hi,

Our logs are filling up with "LockManagerImpl.java:813 Bad lock token: Bad check digit. Token [..]". Is this cause for concern? How can this be avoided?
We are using MySQL for persistence with mostly full versioning on nodes via PHPCR (aka Davex)

regards,
Lukas Kahwe Smith
mls@pooteeweet.org

Re: LockManagerImpl.java:813 Bad lock token: Bad check digit. Token [..]

Posted by Lukas Kahwe Smith <ml...@pooteeweet.org>.
On Feb 10, 2012, at 12:23 , Jukka Zitting wrote:

> That said, the "Bad check digit" issue sounds like something that
> shouldn't have happened even before JCR-3209. Does it only occur with
> the WebDAV layer or can it be reproduced with a local Jackrabbit
> instance? Perhaps we can come up with a more focused fix for the 2.4
> branch that doesn't change the externally visible lock token format
> like JCR-3209 does.


No, only tried via Davex so far.

regards,
Lukas Kahwe Smith
mls@pooteeweet.org

Re: LockManagerImpl.java:813 Bad lock token: Bad check digit. Token [..]

Posted by Julian Reschke <ju...@gmx.de>.
On 2012-02-10 14:08, Jukka Zitting wrote:
> Hi,
>
> On Fri, Feb 10, 2012 at 1:04 PM, Julian Reschke<ju...@gmx.de>  wrote:
>> On 2012-02-10 12:23, Jukka Zitting wrote:
>>> That said, the "Bad check digit" issue sounds like something that
>>> shouldn't have happened even before JCR-3209. Does it only occur with
>>> the WebDAV layer or can it be reproduced with a local Jackrabbit
>>> instance? Perhaps we can come up with a more focused fix for the 2.4
>>> branch that doesn't change the externally visible lock token format
>>> like JCR-3209 does.
>>
>> No, the problem has been around since JCR 2.0, as far as I can tell.
>
> If I understand correctly, the problem here is that the WebDAV layer
> (in 2.x, x<= 4) comes up with its own WedDAV lock tokens also for
> session-scoped JCR locks and tries to pass also those tokens to
> LockManager.addLockToken(). Which then obviously complains.

Right.

>> If it's worth fixing, the best way to fix it would be to align with trunk.
>> Please no diverging strategies!
>
> Agreed, though assuming the above description is correct, it seems
> like only the isForSessionScopedLock() part of JCR-3209 would be
> needed to fix this issue for 2.4 and earlier.

Yes, but to do that the server code needs to be in control over the lock 
token format (it can't rely on what kind of strings the repository 
generates); only then it can detect which tokens are for session scoped 
locks.

> Can we do pick out just that part without affecting the externally
> visible token format? If not, we might just as well consider

That would be a hack which I'd like to avoid.

> backporting all of JCR-3209. Is there any known scenario where doing
> so would break or confuse existing clients?

Well, only broken clients that may have been special-cases for the 
jackrabbit server. Davex should be ok.

Best regards, Julian

Re: LockManagerImpl.java:813 Bad lock token: Bad check digit. Token [..]

Posted by Jukka Zitting <ju...@gmail.com>.
Hi,

On Fri, Feb 10, 2012 at 1:04 PM, Julian Reschke <ju...@gmx.de> wrote:
> On 2012-02-10 12:23, Jukka Zitting wrote:
>> That said, the "Bad check digit" issue sounds like something that
>> shouldn't have happened even before JCR-3209. Does it only occur with
>> the WebDAV layer or can it be reproduced with a local Jackrabbit
>> instance? Perhaps we can come up with a more focused fix for the 2.4
>> branch that doesn't change the externally visible lock token format
>> like JCR-3209 does.
>
> No, the problem has been around since JCR 2.0, as far as I can tell.

If I understand correctly, the problem here is that the WebDAV layer
(in 2.x, x <= 4) comes up with its own WedDAV lock tokens also for
session-scoped JCR locks and tries to pass also those tokens to
LockManager.addLockToken(). Which then obviously complains.

> If it's worth fixing, the best way to fix it would be to align with trunk.
> Please no diverging strategies!

Agreed, though assuming the above description is correct, it seems
like only the isForSessionScopedLock() part of JCR-3209 would be
needed to fix this issue for 2.4 and earlier.

Can we do pick out just that part without affecting the externally
visible token format? If not, we might just as well consider
backporting all of JCR-3209. Is there any known scenario where doing
so would break or confuse existing clients?

BR,

Jukka Zitting

Re: LockManagerImpl.java:813 Bad lock token: Bad check digit. Token [..]

Posted by Julian Reschke <ju...@gmx.de>.
On 2012-02-10 12:23, Jukka Zitting wrote:
> Hi,
>
> On Fri, Feb 10, 2012 at 9:54 AM, Julian Reschke<ju...@gmx.de>  wrote:
>> Should we port *every* fix back? (not a rhetorical question).
>
> Only those that people are asking for (or that we can assume people to
> run into). Additionally, we should ideally only backport low-risk bug
> fixes, not wider improvements or other more risky changes. The main
> focus in a maintenance branch like 2.4 is stability so upgrading from
> 2.4.x to 2.4.(x+1) should never break anything, which limits the
> amount and type of changes that should be backported.
>
> On this specific issue, the mentioned JCR-3209 is a little bit broader
> change that modifies the way lock tokens are handled by the WebDAV
> layer. Thus I'd rather keep it out of the 2.4 branch now that 2.4.0 is
> already out.
>
> That said, the "Bad check digit" issue sounds like something that
> shouldn't have happened even before JCR-3209. Does it only occur with
> the WebDAV layer or can it be reproduced with a local Jackrabbit
> instance? Perhaps we can come up with a more focused fix for the 2.4
> branch that doesn't change the externally visible lock token format
> like JCR-3209 does.

No, the problem has been around since JCR 2.0, as far as I can tell.

If it's worth fixing, the best way to fix it would be to align with 
trunk. Please no diverging strategies!

Best regards, Julian

Re: LockManagerImpl.java:813 Bad lock token: Bad check digit. Token [..]

Posted by Jukka Zitting <ju...@gmail.com>.
Hi,

On Fri, Feb 10, 2012 at 9:54 AM, Julian Reschke <ju...@gmx.de> wrote:
> Should we port *every* fix back? (not a rhetorical question).

Only those that people are asking for (or that we can assume people to
run into). Additionally, we should ideally only backport low-risk bug
fixes, not wider improvements or other more risky changes. The main
focus in a maintenance branch like 2.4 is stability so upgrading from
2.4.x to 2.4.(x+1) should never break anything, which limits the
amount and type of changes that should be backported.

On this specific issue, the mentioned JCR-3209 is a little bit broader
change that modifies the way lock tokens are handled by the WebDAV
layer. Thus I'd rather keep it out of the 2.4 branch now that 2.4.0 is
already out.

That said, the "Bad check digit" issue sounds like something that
shouldn't have happened even before JCR-3209. Does it only occur with
the WebDAV layer or can it be reproduced with a local Jackrabbit
instance? Perhaps we can come up with a more focused fix for the 2.4
branch that doesn't change the externally visible lock token format
like JCR-3209 does.

BR,

Jukka Zitting

Re: LockManagerImpl.java:813 Bad lock token: Bad check digit. Token [..]

Posted by Lukas Kahwe Smith <ml...@pooteeweet.org>.
On Feb 10, 2012, at 09:54 , Julian Reschke wrote:

> On 2012-02-10 09:42, Lukas Kahwe Smith wrote:
>> 
>> On Feb 10, 2012, at 09:39 , Julian Reschke wrote:
>> 
>>> On 2012-02-10 09:24, Lukas Kahwe Smith wrote:
>>>> Hi,
>>>> 
>>>> Our logs are filling up with "LockManagerImpl.java:813 Bad lock token: Bad check digit. Token [..]". Is this cause for concern? How can this be avoided?
>>>> We are using MySQL for persistence with mostly full versioning on nodes via PHPCR (aka Davex)
>>>> 
>>>> regards,
>>>> Lukas Kahwe Smith
>>>> mls@pooteeweet.org
>>> 
>>> This is probably<https://issues.apache.org/jira/browse/JCR-3209>; so running with a trunk build should fix the problem.
>> 
>> 
>> yeah looks like it.
>> so this fix will not go into 2.4.x?
> 
> Well, it's a harmless problem.
> 
> Should we port *every* fix back? (not a rhetorical question).


Yeah it seems harmless, but it pollutes our logs, so I wouldnt mind getting rid of it. :)

regards,
Lukas Kahwe Smith
mls@pooteeweet.org

Re: LockManagerImpl.java:813 Bad lock token: Bad check digit. Token [..]

Posted by Julian Reschke <ju...@gmx.de>.
On 2012-02-10 09:42, Lukas Kahwe Smith wrote:
>
> On Feb 10, 2012, at 09:39 , Julian Reschke wrote:
>
>> On 2012-02-10 09:24, Lukas Kahwe Smith wrote:
>>> Hi,
>>>
>>> Our logs are filling up with "LockManagerImpl.java:813 Bad lock token: Bad check digit. Token [..]". Is this cause for concern? How can this be avoided?
>>> We are using MySQL for persistence with mostly full versioning on nodes via PHPCR (aka Davex)
>>>
>>> regards,
>>> Lukas Kahwe Smith
>>> mls@pooteeweet.org
>>
>> This is probably<https://issues.apache.org/jira/browse/JCR-3209>; so running with a trunk build should fix the problem.
>
>
> yeah looks like it.
> so this fix will not go into 2.4.x?

Well, it's a harmless problem.

Should we port *every* fix back? (not a rhetorical question).

Best regards, Julian

Re: LockManagerImpl.java:813 Bad lock token: Bad check digit. Token [..]

Posted by Lukas Kahwe Smith <ml...@pooteeweet.org>.
On Feb 10, 2012, at 09:39 , Julian Reschke wrote:

> On 2012-02-10 09:24, Lukas Kahwe Smith wrote:
>> Hi,
>> 
>> Our logs are filling up with "LockManagerImpl.java:813 Bad lock token: Bad check digit. Token [..]". Is this cause for concern? How can this be avoided?
>> We are using MySQL for persistence with mostly full versioning on nodes via PHPCR (aka Davex)
>> 
>> regards,
>> Lukas Kahwe Smith
>> mls@pooteeweet.org
> 
> This is probably <https://issues.apache.org/jira/browse/JCR-3209>; so running with a trunk build should fix the problem.


yeah looks like it.
so this fix will not go into 2.4.x?

regards,
Lukas Kahwe Smith
mls@pooteeweet.org

Re: LockManagerImpl.java:813 Bad lock token: Bad check digit. Token [..]

Posted by Julian Reschke <ju...@gmx.de>.
On 2012-02-10 09:24, Lukas Kahwe Smith wrote:
> Hi,
>
> Our logs are filling up with "LockManagerImpl.java:813 Bad lock token: Bad check digit. Token [..]". Is this cause for concern? How can this be avoided?
> We are using MySQL for persistence with mostly full versioning on nodes via PHPCR (aka Davex)
>
> regards,
> Lukas Kahwe Smith
> mls@pooteeweet.org

This is probably <https://issues.apache.org/jira/browse/JCR-3209>; so 
running with a trunk build should fix the problem.

Best regards, Julian