You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Jaka Jaksic (JIRA)" <ji...@apache.org> on 2006/08/31 08:32:22 UTC
[jira] Created: (JCR-551) Null values cause BLOB corruption
Null values cause BLOB corruption
---------------------------------
Key: JCR-551
URL: http://issues.apache.org/jira/browse/JCR-551
Project: Jackrabbit
Issue Type: Bug
Components: core
Affects Versions: 1.0.1
Reporter: Jaka Jaksic
Priority: Critical
Using the file persistence manager (not sure about other managers) there is a way to produce a corrupt property BLOB, which can then be neither read nor modified nor deleted. Once this happens, Jackrabbit starts throwing "failed to read property state" exceptions every time it hits that property, and essentially becomes useless until the BLOB is fixed (e.g. with a hex editor).
The problem is caused by passing a null value to a setProperty overload other than setProperty(String, Value).
For example:
node.setProperty("corruptionTest", null, PropertyType.STRING);
This produces a corrupt BLOB (the data in the BLOB indicates value count = 1, then the BLOB ends) instead of removing the property or at least throwing an exception.
setProperty(String, Value) properly removes the property if a null is passed to it, as documented in the JCR spec. I think other overloads should do the same, although this is not explicitly stated in the spec. In any case they should not corrupt repository data.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (JCR-551) Null values cause BLOB corruption
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 9/3/06, Carlos Villegas <ca...@uniscope.jp> wrote:
> I have noticed that handling of nulls in the RMI client is inconsistent,
> some methods don't handle nulls correctly. We managed to sort out which
> methods work and are using that way. This doesn't happen with the local
> client. I was going to report this but I haven't had time to put a test
> case.
Good point. Incorrect null handling is most likely related to the
local/remote mapping not being prepared for null values. There were
some issues reported about that earlier, but I haven't gone through
the entire codebase looking for them systematically.
I can probably identify and fix the problems quite fast even if you
can just identify the troublesome methods, so a Jira issue even
without a test case would be valuable.
BR,
Jukka Zitting
--
Yukatan - http://yukatan.fi/ - info@yukatan.fi
Software craftsmanship, JCR consulting, and Java development
Re: [jira] Commented: (JCR-551) Null values cause BLOB corruption
Posted by Carlos Villegas <ca...@uniscope.jp>.
In your application, are you accessing the repository remotely from the
RMI client?
I have noticed that handling of nulls in the RMI client is inconsistent,
some methods don't handle nulls correctly. We managed to sort out which
methods work and are using that way. This doesn't happen with the local
client. I was going to report this but I haven't had time to put a test
case.
Carlos
Jaka Jaksic (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/JCR-551?page=comments#action_12432261 ]
>
> Jaka Jaksic commented on JCR-551:
> ---------------------------------
>
> Hey, Stefan.. This is rather embarrassing, but as I went to prepare the stand-alone test case, I was unable to reproduce it either. I used the same configuration (as much as I could), but no matter what I did, if I set the property to null, the BLOB was simply deleted, just like it should be. I really don't know what could have made the difference in my application (the bug was perfectly reproducible there - occured plenty of times in a fresh repository etc.), and I still think this bug does exist, but it is obviously not as common and as critical as I thought. So let's just leave it at that for now and I'll get back to you if I manage to learn more about it. I'm really sorry for wasting your time.
>
>> Null values cause BLOB corruption
>> ---------------------------------
>>
>> Key: JCR-551
>> URL: http://issues.apache.org/jira/browse/JCR-551
>> Project: Jackrabbit
>> Issue Type: Bug
>> Components: core
>> Affects Versions: 1.0.1
>> Reporter: Jaka Jaksic
>> Assigned To: Stefan Guggisberg
>> Priority: Critical
>>
>> Using the file persistence manager (not sure about other managers) there is a way to produce a corrupt property BLOB, which can then be neither read nor modified nor deleted. Once this happens, Jackrabbit starts throwing "failed to read property state" exceptions every time it hits that property, and essentially becomes useless until the BLOB is fixed (e.g. with a hex editor).
>> The problem is caused by passing a null value to a setProperty overload other than setProperty(String, Value).
>> For example:
>> node.setProperty("corruptionTest", null, PropertyType.STRING);
>> This produces a corrupt BLOB (the data in the BLOB indicates value count = 1, then the BLOB ends) instead of removing the property or at least throwing an exception.
>> setProperty(String, Value) properly removes the property if a null is passed to it, as documented in the JCR spec. I think other overloads should do the same, although this is not explicitly stated in the spec. In any case they should not corrupt repository data.
>
[jira] Commented: (JCR-551) Null values cause BLOB corruption
Posted by "Jaka Jaksic (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-551?page=comments#action_12432261 ]
Jaka Jaksic commented on JCR-551:
---------------------------------
Hey, Stefan.. This is rather embarrassing, but as I went to prepare the stand-alone test case, I was unable to reproduce it either. I used the same configuration (as much as I could), but no matter what I did, if I set the property to null, the BLOB was simply deleted, just like it should be. I really don't know what could have made the difference in my application (the bug was perfectly reproducible there - occured plenty of times in a fresh repository etc.), and I still think this bug does exist, but it is obviously not as common and as critical as I thought. So let's just leave it at that for now and I'll get back to you if I manage to learn more about it. I'm really sorry for wasting your time.
> Null values cause BLOB corruption
> ---------------------------------
>
> Key: JCR-551
> URL: http://issues.apache.org/jira/browse/JCR-551
> Project: Jackrabbit
> Issue Type: Bug
> Components: core
> Affects Versions: 1.0.1
> Reporter: Jaka Jaksic
> Assigned To: Stefan Guggisberg
> Priority: Critical
>
> Using the file persistence manager (not sure about other managers) there is a way to produce a corrupt property BLOB, which can then be neither read nor modified nor deleted. Once this happens, Jackrabbit starts throwing "failed to read property state" exceptions every time it hits that property, and essentially becomes useless until the BLOB is fixed (e.g. with a hex editor).
> The problem is caused by passing a null value to a setProperty overload other than setProperty(String, Value).
> For example:
> node.setProperty("corruptionTest", null, PropertyType.STRING);
> This produces a corrupt BLOB (the data in the BLOB indicates value count = 1, then the BLOB ends) instead of removing the property or at least throwing an exception.
> setProperty(String, Value) properly removes the property if a null is passed to it, as documented in the JCR spec. I think other overloads should do the same, although this is not explicitly stated in the spec. In any case they should not corrupt repository data.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-551) Null values cause BLOB corruption
Posted by "Stefan Guggisberg (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-551?page=comments#action_12432160 ]
Stefan Guggisberg commented on JCR-551:
---------------------------------------
jaka,
i already wasted a considerable amount of time trying to reproduce your problem and i am still unable to reproduce it.
i am getting tired of guessing what your application code might look like.
again, please provide a simple self-contained test case that includes all relevant information (configs, node types etc.).
otherwise i am afraid that i can't help you and would have to close this issue.
> Null values cause BLOB corruption
> ---------------------------------
>
> Key: JCR-551
> URL: http://issues.apache.org/jira/browse/JCR-551
> Project: Jackrabbit
> Issue Type: Bug
> Components: core
> Affects Versions: 1.0.1
> Reporter: Jaka Jaksic
> Assigned To: Stefan Guggisberg
> Priority: Critical
>
> Using the file persistence manager (not sure about other managers) there is a way to produce a corrupt property BLOB, which can then be neither read nor modified nor deleted. Once this happens, Jackrabbit starts throwing "failed to read property state" exceptions every time it hits that property, and essentially becomes useless until the BLOB is fixed (e.g. with a hex editor).
> The problem is caused by passing a null value to a setProperty overload other than setProperty(String, Value).
> For example:
> node.setProperty("corruptionTest", null, PropertyType.STRING);
> This produces a corrupt BLOB (the data in the BLOB indicates value count = 1, then the BLOB ends) instead of removing the property or at least throwing an exception.
> setProperty(String, Value) properly removes the property if a null is passed to it, as documented in the JCR spec. I think other overloads should do the same, although this is not explicitly stated in the spec. In any case they should not corrupt repository data.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-551) Null values cause BLOB corruption
Posted by "Jaka Jaksic (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-551?page=comments#action_12431879 ]
Jaka Jaksic commented on JCR-551:
---------------------------------
The exception will occur the next time the property gets read from the file system. So just call node.refresh(false) afterwards, or something like that, and it should "work".
> Null values cause BLOB corruption
> ---------------------------------
>
> Key: JCR-551
> URL: http://issues.apache.org/jira/browse/JCR-551
> Project: Jackrabbit
> Issue Type: Bug
> Components: core
> Affects Versions: 1.0.1
> Reporter: Jaka Jaksic
> Assigned To: Stefan Guggisberg
> Priority: Critical
>
> Using the file persistence manager (not sure about other managers) there is a way to produce a corrupt property BLOB, which can then be neither read nor modified nor deleted. Once this happens, Jackrabbit starts throwing "failed to read property state" exceptions every time it hits that property, and essentially becomes useless until the BLOB is fixed (e.g. with a hex editor).
> The problem is caused by passing a null value to a setProperty overload other than setProperty(String, Value).
> For example:
> node.setProperty("corruptionTest", null, PropertyType.STRING);
> This produces a corrupt BLOB (the data in the BLOB indicates value count = 1, then the BLOB ends) instead of removing the property or at least throwing an exception.
> setProperty(String, Value) properly removes the property if a null is passed to it, as documented in the JCR spec. I think other overloads should do the same, although this is not explicitly stated in the spec. In any case they should not corrupt repository data.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (JCR-551) Null values cause BLOB corruption
Posted by "Stefan Guggisberg (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-551?page=all ]
Stefan Guggisberg resolved JCR-551.
-----------------------------------
Resolution: Cannot Reproduce
i am unable to reproduce the described behavior. please provide a simple selfcontained test case.
btw:
> For example:
> node.setProperty("corruptionTest", null, PropertyType.STRING);
this doesn't compile (ambiguous method call).
> Null values cause BLOB corruption
> ---------------------------------
>
> Key: JCR-551
> URL: http://issues.apache.org/jira/browse/JCR-551
> Project: Jackrabbit
> Issue Type: Bug
> Components: core
> Affects Versions: 1.0.1
> Reporter: Jaka Jaksic
> Assigned To: Stefan Guggisberg
> Priority: Critical
>
> Using the file persistence manager (not sure about other managers) there is a way to produce a corrupt property BLOB, which can then be neither read nor modified nor deleted. Once this happens, Jackrabbit starts throwing "failed to read property state" exceptions every time it hits that property, and essentially becomes useless until the BLOB is fixed (e.g. with a hex editor).
> The problem is caused by passing a null value to a setProperty overload other than setProperty(String, Value).
> For example:
> node.setProperty("corruptionTest", null, PropertyType.STRING);
> This produces a corrupt BLOB (the data in the BLOB indicates value count = 1, then the BLOB ends) instead of removing the property or at least throwing an exception.
> setProperty(String, Value) properly removes the property if a null is passed to it, as documented in the JCR spec. I think other overloads should do the same, although this is not explicitly stated in the spec. In any case they should not corrupt repository data.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (JCR-551) Null values cause BLOB corruption
Posted by "Jaka Jaksic (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-551?page=comments#action_12431877 ]
Jaka Jaksic commented on JCR-551:
---------------------------------
Oh, it's actually like this:
String propertyValue = null;
node.setProperty("corruptionTest", propertyValue, PropertyType.STRING);
session.save();
You can insert this into any simple test case.
(Of course, I do not intentionally set the value to null in my code - I have a parametrized function that sets some items' properties, which can also be null, and I expected the property to be automatically erased in that case.)
> Null values cause BLOB corruption
> ---------------------------------
>
> Key: JCR-551
> URL: http://issues.apache.org/jira/browse/JCR-551
> Project: Jackrabbit
> Issue Type: Bug
> Components: core
> Affects Versions: 1.0.1
> Reporter: Jaka Jaksic
> Assigned To: Stefan Guggisberg
> Priority: Critical
>
> Using the file persistence manager (not sure about other managers) there is a way to produce a corrupt property BLOB, which can then be neither read nor modified nor deleted. Once this happens, Jackrabbit starts throwing "failed to read property state" exceptions every time it hits that property, and essentially becomes useless until the BLOB is fixed (e.g. with a hex editor).
> The problem is caused by passing a null value to a setProperty overload other than setProperty(String, Value).
> For example:
> node.setProperty("corruptionTest", null, PropertyType.STRING);
> This produces a corrupt BLOB (the data in the BLOB indicates value count = 1, then the BLOB ends) instead of removing the property or at least throwing an exception.
> setProperty(String, Value) properly removes the property if a null is passed to it, as documented in the JCR spec. I think other overloads should do the same, although this is not explicitly stated in the spec. In any case they should not corrupt repository data.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (JCR-551) Null values cause BLOB corruption
Posted by "Stefan Guggisberg (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-551?page=all ]
Stefan Guggisberg closed JCR-551.
---------------------------------
no problem, jaka.
i'll close the issue for now as 'cannot reproduce'.
feel free to reopen it if you manage to reproduce it
with a test case or if you have more information about it.
cheers
stefan
> Null values cause BLOB corruption
> ---------------------------------
>
> Key: JCR-551
> URL: http://issues.apache.org/jira/browse/JCR-551
> Project: Jackrabbit
> Issue Type: Bug
> Components: core
> Affects Versions: 1.0.1
> Reporter: Jaka Jaksic
> Assigned To: Stefan Guggisberg
> Priority: Critical
>
> Using the file persistence manager (not sure about other managers) there is a way to produce a corrupt property BLOB, which can then be neither read nor modified nor deleted. Once this happens, Jackrabbit starts throwing "failed to read property state" exceptions every time it hits that property, and essentially becomes useless until the BLOB is fixed (e.g. with a hex editor).
> The problem is caused by passing a null value to a setProperty overload other than setProperty(String, Value).
> For example:
> node.setProperty("corruptionTest", null, PropertyType.STRING);
> This produces a corrupt BLOB (the data in the BLOB indicates value count = 1, then the BLOB ends) instead of removing the property or at least throwing an exception.
> setProperty(String, Value) properly removes the property if a null is passed to it, as documented in the JCR spec. I think other overloads should do the same, although this is not explicitly stated in the spec. In any case they should not corrupt repository data.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (JCR-551) Null values cause BLOB corruption
Posted by "Stefan Guggisberg (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/JCR-551?page=all ]
Stefan Guggisberg reassigned JCR-551:
-------------------------------------
Assignee: Stefan Guggisberg
> Null values cause BLOB corruption
> ---------------------------------
>
> Key: JCR-551
> URL: http://issues.apache.org/jira/browse/JCR-551
> Project: Jackrabbit
> Issue Type: Bug
> Components: core
> Affects Versions: 1.0.1
> Reporter: Jaka Jaksic
> Assigned To: Stefan Guggisberg
> Priority: Critical
>
> Using the file persistence manager (not sure about other managers) there is a way to produce a corrupt property BLOB, which can then be neither read nor modified nor deleted. Once this happens, Jackrabbit starts throwing "failed to read property state" exceptions every time it hits that property, and essentially becomes useless until the BLOB is fixed (e.g. with a hex editor).
> The problem is caused by passing a null value to a setProperty overload other than setProperty(String, Value).
> For example:
> node.setProperty("corruptionTest", null, PropertyType.STRING);
> This produces a corrupt BLOB (the data in the BLOB indicates value count = 1, then the BLOB ends) instead of removing the property or at least throwing an exception.
> setProperty(String, Value) properly removes the property if a null is passed to it, as documented in the JCR spec. I think other overloads should do the same, although this is not explicitly stated in the spec. In any case they should not corrupt repository data.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira