[jira] Commented: (JCR-1525) Jackrabbit depends on Oracle driver for BLOB support in Oracle versions previous than 10.2
[ https://issues.apache.org/jira/browse/JCR-1525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12621820#action_12621820 ] Esteban Franqueiro commented on JCR-1525: - Hi all. What should we do regarding this issue? I've been running this code for some time now and haven't had any issues. Should we apply it to trunk? Or should we wait? Regards, > Jackrabbit depends on Oracle driver for BLOB support in Oracle versions > previous than 10.2 > -- > > Key: JCR-1525 > URL: https://issues.apache.org/jira/browse/JCR-1525 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-core >Reporter: Esteban Franqueiro > Attachments: JCR-1525.patch > > > In Oracle versions previous to 10.2, Jackrabbit explicitly uses a class from > the Oracle driver to provide BLOB support (see OracleFileSystem.init()). This > special handling is no longer necesary for Oracle 10.2+, so we should provide > a new implementation. As discussed on the list, we can create a new class for > Oracle 10.2+, make it inherit from DbFileSystem, and override the > createSchema(), and table space related methods, which are the ones that need > special handling. Furthermore, we could refactor the current OracleFileSystem > and break it into two clases, one of them to keep the current behavior and a > new one to keep the common code (which we could rename to > OracleBaseFileSystem or similar, to maintain compatiblity with code that uses > OracleFileSystem for versions previous to 10.2). Then we make the > Oracle10FileSystem inherit from the latter. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1705) Reduce memory usage of transient nodes
[ https://issues.apache.org/jira/browse/JCR-1705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12619540#action_12619540 ] Esteban Franqueiro commented on JCR-1705: - +1 I remember a few discussions about performance/memory consumption. We should get into that sometime, perhaps pre-1.5? Also, like Jukka said, maybe we should try to clean up NodeState sometime :) Regards, > Reduce memory usage of transient nodes > -- > > Key: JCR-1705 > URL: https://issues.apache.org/jira/browse/JCR-1705 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-core >Reporter: Marcel Reutegger >Priority: Minor > Attachments: JCR-1705.patch > > > When adding lots of transient nodes, most of them don't have child nodes > because they are leafs. The attached patch initializes > NodeState.childNodeEntries with an unmodifiable empty ChildNodeEntries > instance and turns it into a modifiable one only when needed. > Running a test with 100k nodes (10 children per node) the memory consumption > for child node entries drops from 42MB to 12MB with this patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (JCR-1520) DatabaseFileSystem's logger references the wrong class
[ https://issues.apache.org/jira/browse/JCR-1520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Esteban Franqueiro resolved JCR-1520. - Resolution: Fixed Fix Version/s: 1.5 Resolved as suggested in revision #672286. > DatabaseFileSystem's logger references the wrong class > -- > > Key: JCR-1520 > URL: https://issues.apache.org/jira/browse/JCR-1520 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-core >Affects Versions: 1.4, 1.5 >Reporter: Esteban Franqueiro > Fix For: 1.5 > > Attachments: JCR-1520.patch > > > In DatabaseFileSystem, the logger is constructed as > private static Logger log = LoggerFactory.getLogger(DbFileSystem.class); > It should be constructed as: > private static Logger log = LoggerFactory.getLogger(DatabaseFileSystem.class); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1520) DatabaseFileSystem's logger references the wrong class
[ https://issues.apache.org/jira/browse/JCR-1520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Esteban Franqueiro updated JCR-1520: Summary: DatabaseFileSystem's logger references the wrong class (was: DatabaseFileSistem's logger references the wrong class) > DatabaseFileSystem's logger references the wrong class > -- > > Key: JCR-1520 > URL: https://issues.apache.org/jira/browse/JCR-1520 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-core >Affects Versions: 1.4, 1.5 >Reporter: Esteban Franqueiro > Attachments: JCR-1520.patch > > > In DatabaseFileSystem, the logger is constructed as > private static Logger log = LoggerFactory.getLogger(DbFileSystem.class); > It should be constructed as: > private static Logger log = LoggerFactory.getLogger(DatabaseFileSystem.class); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1600) Remove noLockHack in SharedItemStateManager
[ https://issues.apache.org/jira/browse/JCR-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12596496#action_12596496 ] Esteban Franqueiro commented on JCR-1600: - Is the fine grained locking strategy being tested? > Remove noLockHack in SharedItemStateManager > --- > > Key: JCR-1600 > URL: https://issues.apache.org/jira/browse/JCR-1600 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-core >Reporter: Marcel Reutegger >Priority: Minor > Attachments: JCR-1600.patch > > > With the increased test coverage, specifically the recently added > multi-threaded tests, I'm reasonably confident that the noLockHack in > SharedItemStateManager is not needed anymore. > Attached patch removes the hack. All tests still pass, including the daily > integration tests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1566) Data Store: DB2 fails to create the table
[
https://issues.apache.org/jira/browse/JCR-1566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12594500#action_12594500
]
Esteban Franqueiro commented on JCR-1566:
-
Thanks Jukka!
I'm on vacations right now, so I can't do much work :)
> Data Store: DB2 fails to create the table
> -
>
> Key: JCR-1566
> URL: https://issues.apache.org/jira/browse/JCR-1566
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-core
>Reporter: Esteban Franqueiro
> Fix For: core 1.4.4
>
>
> DB2 throws an exception(1) when creating the table. The correct SQL sentence
> to create it is:
> createTable=CREATE TABLE ${tablePrefix}${table}(ID VARCHAR(255) PRIMARY KEY
> NOT NULL, LENGTH BIGINT, LAST_MODIFIED BIGINT, DATA BLOB(1000M))
> (1): Sorry but I don't have the exception information since I made this
> change a few weeks ago.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1566) Data Store: DB2 fails to create the table
Data Store: DB2 fails to create the table
-
Key: JCR-1566
URL: https://issues.apache.org/jira/browse/JCR-1566
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-core
Reporter: Esteban Franqueiro
DB2 throws an exception(1) when creating the table. The correct SQL sentence to
create it is:
createTable=CREATE TABLE ${tablePrefix}${table}(ID VARCHAR(255) PRIMARY KEY NOT
NULL, LENGTH BIGINT, LAST_MODIFIED BIGINT, DATA BLOB(1000M))
(1): Sorry but I don't have the exception information since I made this change
a few weeks ago.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1560) Data Store: Oracle fails to create the table
[
https://issues.apache.org/jira/browse/JCR-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12593031#action_12593031
]
Esteban Franqueiro commented on JCR-1560:
-
You're correct. But I used the following line in oracle.properties:
createTable=CREATE TABLE ${tablePrefix}${table}(ID VARCHAR2(255) PRIMARY KEY,
LENGTH NUMBER, LAST_MODIFIED NUMBER, DATA BLOB)
BTW, I also had to modify db2.properties. Should we open a new issue?
> Data Store: Oracle fails to create the table
>
>
> Key: JCR-1560
> URL: https://issues.apache.org/jira/browse/JCR-1560
> Project: Jackrabbit
> Issue Type: Bug
>Affects Versions: 1.4
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
> Fix For: core 1.4.3
>
>
> When using an Oracle database, the following exception occurs when trying to
> create the table: ORA.00902: invalid datatype
> The problem is that Oracle doesn't support the data type BIGINT. Instead,
> LONG should be used.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1525) Jackrabbit depends on Oracle driver for BLOB support in Oracle versions previous than 10.2
[ https://issues.apache.org/jira/browse/JCR-1525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Esteban Franqueiro updated JCR-1525: Attachment: JCR-1525.patch This patch applies the suggested fix. We should decide what to do regarding what I mentioned in my previous comments. As suggested by Thomas, this doesn't include changes for the older PMs. I tested it on Oracle 10.2.0.3.0 and all tests passed. > Jackrabbit depends on Oracle driver for BLOB support in Oracle versions > previous than 10.2 > -- > > Key: JCR-1525 > URL: https://issues.apache.org/jira/browse/JCR-1525 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-core >Reporter: Esteban Franqueiro > Attachments: JCR-1525.patch > > > In Oracle versions previous to 10.2, Jackrabbit explicitly uses a class from > the Oracle driver to provide BLOB support (see OracleFileSystem.init()). This > special handling is no longer necesary for Oracle 10.2+, so we should provide > a new implementation. As discussed on the list, we can create a new class for > Oracle 10.2+, make it inherit from DbFileSystem, and override the > createSchema(), and table space related methods, which are the ones that need > special handling. Furthermore, we could refactor the current OracleFileSystem > and break it into two clases, one of them to keep the current behavior and a > new one to keep the common code (which we could rename to > OracleBaseFileSystem or similar, to maintain compatiblity with code that uses > OracleFileSystem for versions previous to 10.2). Then we make the > Oracle10FileSystem inherit from the latter. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1525) Jackrabbit depends on Oracle driver for BLOB support in Oracle versions previous than 10.2
[ https://issues.apache.org/jira/browse/JCR-1525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12590494#action_12590494 ] Esteban Franqueiro commented on JCR-1525: - Is it worth doing this work for the Oracle DB Persistence Managers (not the bundle PMs) too? The bundle PMs for Oracle already support 10.2+, but there's a name mismatch because there's an Oracle9PM, and OraclePM is for 10+. > Jackrabbit depends on Oracle driver for BLOB support in Oracle versions > previous than 10.2 > -- > > Key: JCR-1525 > URL: https://issues.apache.org/jira/browse/JCR-1525 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-core >Reporter: Esteban Franqueiro > > In Oracle versions previous to 10.2, Jackrabbit explicitly uses a class from > the Oracle driver to provide BLOB support (see OracleFileSystem.init()). This > special handling is no longer necesary for Oracle 10.2+, so we should provide > a new implementation. As discussed on the list, we can create a new class for > Oracle 10.2+, make it inherit from DbFileSystem, and override the > createSchema(), and table space related methods, which are the ones that need > special handling. Furthermore, we could refactor the current OracleFileSystem > and break it into two clases, one of them to keep the current behavior and a > new one to keep the common code (which we could rename to > OracleBaseFileSystem or similar, to maintain compatiblity with code that uses > OracleFileSystem for versions previous to 10.2). Then we make the > Oracle10FileSystem inherit from the latter. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1525) Jackrabbit depends on Oracle driver for BLOB support in Oracle versions previous than 10.2
[ https://issues.apache.org/jira/browse/JCR-1525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12590197#action_12590197 ] Esteban Franqueiro commented on JCR-1525: - I'm working on this refactoring and I ended up with an empty Oracle10R2FileSystem. From a code point of view this class should be removed, but from a user's perspective, I think its more clear to have a class with a more accurate name. The other possibility is to rename the already mentioned OracleBaseFaileSystem as Oracle10R2FileSystem, and make OracleFileSystem inheriit from it. I don't like this either. WDYYT? Regards, > Jackrabbit depends on Oracle driver for BLOB support in Oracle versions > previous than 10.2 > -- > > Key: JCR-1525 > URL: https://issues.apache.org/jira/browse/JCR-1525 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-core >Reporter: Esteban Franqueiro > > In Oracle versions previous to 10.2, Jackrabbit explicitly uses a class from > the Oracle driver to provide BLOB support (see OracleFileSystem.init()). This > special handling is no longer necesary for Oracle 10.2+, so we should provide > a new implementation. As discussed on the list, we can create a new class for > Oracle 10.2+, make it inherit from DbFileSystem, and override the > createSchema(), and table space related methods, which are the ones that need > special handling. Furthermore, we could refactor the current OracleFileSystem > and break it into two clases, one of them to keep the current behavior and a > new one to keep the common code (which we could rename to > OracleBaseFileSystem or similar, to maintain compatiblity with code that uses > OracleFileSystem for versions previous to 10.2). Then we make the > Oracle10FileSystem inherit from the latter. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1525) Jackrabbit depends on Oracle driver for BLOB support in Oracle versions previous than 10.2
Jackrabbit depends on Oracle driver for BLOB support in Oracle versions previous than 10.2 -- Key: JCR-1525 URL: https://issues.apache.org/jira/browse/JCR-1525 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Reporter: Esteban Franqueiro In Oracle versions previous to 10.2, Jackrabbit explicitly uses a class from the Oracle driver to provide BLOB support (see OracleFileSystem.init()). This special handling is no longer necesary for Oracle 10.2+, so we should provide a new implementation. As discussed on the list, we can create a new class for Oracle 10.2+, make it inherit from DbFileSystem, and override the createSchema(), and table space related methods, which are the ones that need special handling. Furthermore, we could refactor the current OracleFileSystem and break it into two clases, one of them to keep the current behavior and a new one to keep the common code (which we could rename to OracleBaseFileSystem or similar, to maintain compatiblity with code that uses OracleFileSystem for versions previous to 10.2). Then we make the Oracle10FileSystem inherit from the latter. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1520) DatabaseFileSistem's logger references the wrong class
[ https://issues.apache.org/jira/browse/JCR-1520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12586398#action_12586398 ] Esteban Franqueiro commented on JCR-1520: - I thought you meant that in your email comment, but since I didn't have confirmation that everything was already set up, I posted the patch anyway. I will set everything up and fix it asap. Thanks! > DatabaseFileSistem's logger references the wrong class > -- > > Key: JCR-1520 > URL: https://issues.apache.org/jira/browse/JCR-1520 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-core >Affects Versions: 1.4, 1.5 >Reporter: Esteban Franqueiro > Attachments: JCR-1520.patch > > > In DatabaseFileSystem, the logger is constructed as > private static Logger log = LoggerFactory.getLogger(DbFileSystem.class); > It should be constructed as: > private static Logger log = LoggerFactory.getLogger(DatabaseFileSystem.class); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1520) DatabaseFileSistem's logger references the wrong class
[ https://issues.apache.org/jira/browse/JCR-1520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Esteban Franqueiro updated JCR-1520: Attachment: JCR-1520.patch This patch references the right class. > DatabaseFileSistem's logger references the wrong class > -- > > Key: JCR-1520 > URL: https://issues.apache.org/jira/browse/JCR-1520 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-core >Affects Versions: 1.4, 1.5 >Reporter: Esteban Franqueiro > Attachments: JCR-1520.patch > > > In DatabaseFileSystem, the logger is constructed as > private static Logger log = LoggerFactory.getLogger(DbFileSystem.class); > It should be constructed as: > private static Logger log = LoggerFactory.getLogger(DatabaseFileSystem.class); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1520) DatabaseFileSistem's logger references the wrong class
DatabaseFileSistem's logger references the wrong class -- Key: JCR-1520 URL: https://issues.apache.org/jira/browse/JCR-1520 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Affects Versions: 1.4, 1.5 Reporter: Esteban Franqueiro In DatabaseFileSystem, the logger is constructed as private static Logger log = LoggerFactory.getLogger(DbFileSystem.class); It should be constructed as: private static Logger log = LoggerFactory.getLogger(DatabaseFileSystem.class); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1504) MS Excel Mime Type missing in MsExcelTextExtractor
[ https://issues.apache.org/jira/browse/JCR-1504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12583073#action_12583073 ] Esteban Franqueiro commented on JCR-1504: - > The patch does not work. There must be an individual String for each mime > type. Silly me. Sorry for the trouble. Thanks for fixing this. > MS Excel Mime Type missing in MsExcelTextExtractor > --- > > Key: JCR-1504 > URL: https://issues.apache.org/jira/browse/JCR-1504 > Project: Jackrabbit > Issue Type: Bug > Components: jackrabbit-jcr-server, jackrabbit-text-extractors >Affects Versions: 1.4 >Reporter: Dirk Feufel > Fix For: 1.5 > > Attachments: jcr-1504.patch > > > The MsExcelTextExtractor listens to mime type "application/vnd.ms-excel", but > storing excels will result in mime type "application/msexcel", too. Such > tagged files will not be indexed by the MsExcelTextExtractor. The class > should register itself to both mime types like the MsWordTextExtractor does. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1504) MS Excel Mime Type missing in MsExcelTextExtractor
[ https://issues.apache.org/jira/browse/JCR-1504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Esteban Franqueiro updated JCR-1504: Attachment: jcr-1504.patch Trivial patch implementing the suggested fix. > MS Excel Mime Type missing in MsExcelTextExtractor > --- > > Key: JCR-1504 > URL: https://issues.apache.org/jira/browse/JCR-1504 > Project: Jackrabbit > Issue Type: Bug > Components: jackrabbit-text-extractors >Affects Versions: 1.4 >Reporter: Dirk Feufel > Attachments: jcr-1504.patch > > > The MsExcelTextExtractor listens to mime type "application/vnd.ms-excel", but > storing excels will result in mime type "application/msexcel", too. Such > tagged files will not be indexed by the MsExcelTextExtractor. The class > should register itself to both mime types like the MsWordTextExtractor does. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1388) Jackrabbit does not allow concurrent reads to the data store if copyWhenReading=false
[ https://issues.apache.org/jira/browse/JCR-1388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Esteban Franqueiro updated JCR-1388: Attachment: (was: JCR-1388-datastore-concurrent-reads.10.patch) > Jackrabbit does not allow concurrent reads to the data store if > copyWhenReading=false > - > > Key: JCR-1388 > URL: https://issues.apache.org/jira/browse/JCR-1388 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-core >Affects Versions: 1.4 > Environment: WinXP x64, Eclipse, remote SQL Server 2005 >Reporter: Esteban Franqueiro > Attachments: JCR-1388-datastore-concurrent-reads.10.patch, > JCR-1388-datastore-concurrent-reads.2.patch, > JCR-1388-datastore-concurrent-reads.4.patch, > JCR-1388-datastore-concurrent-reads.8.patch, > JCR-1388-datastore-concurrent-reads.patch, TestTwoGetStreams.java > > > Jackrabbit does not allow concurrent reads to the data store if > copyWhenReading=false, even if maxConnections>1. > See JCR-1184 for a test for this problem (run it with copyWhenReading=false). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1388) Jackrabbit does not allow concurrent reads to the data store if copyWhenReading=false
[ https://issues.apache.org/jira/browse/JCR-1388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Esteban Franqueiro updated JCR-1388: Attachment: JCR-1388-datastore-concurrent-reads.10.patch I agree with you Thomas. Here's the corrected patch. > Jackrabbit does not allow concurrent reads to the data store if > copyWhenReading=false > - > > Key: JCR-1388 > URL: https://issues.apache.org/jira/browse/JCR-1388 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-core >Affects Versions: 1.4 > Environment: WinXP x64, Eclipse, remote SQL Server 2005 >Reporter: Esteban Franqueiro > Attachments: JCR-1388-datastore-concurrent-reads.10.patch, > JCR-1388-datastore-concurrent-reads.2.patch, > JCR-1388-datastore-concurrent-reads.4.patch, > JCR-1388-datastore-concurrent-reads.8.patch, > JCR-1388-datastore-concurrent-reads.patch, TestTwoGetStreams.java > > > Jackrabbit does not allow concurrent reads to the data store if > copyWhenReading=false, even if maxConnections>1. > See JCR-1184 for a test for this problem (run it with copyWhenReading=false). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1388) Jackrabbit does not allow concurrent reads to the data store if copyWhenReading=false
[ https://issues.apache.org/jira/browse/JCR-1388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Esteban Franqueiro updated JCR-1388: Attachment: JCR-1388-datastore-concurrent-reads.10.patch Oops, wrong file. Here is the right one. > Jackrabbit does not allow concurrent reads to the data store if > copyWhenReading=false > - > > Key: JCR-1388 > URL: https://issues.apache.org/jira/browse/JCR-1388 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-core >Affects Versions: 1.4 > Environment: WinXP x64, Eclipse, remote SQL Server 2005 >Reporter: Esteban Franqueiro > Attachments: JCR-1388-datastore-concurrent-reads.10.patch, > JCR-1388-datastore-concurrent-reads.2.patch, > JCR-1388-datastore-concurrent-reads.4.patch, > JCR-1388-datastore-concurrent-reads.8.patch, > JCR-1388-datastore-concurrent-reads.patch, TestTwoGetStreams.java > > > Jackrabbit does not allow concurrent reads to the data store if > copyWhenReading=false, even if maxConnections>1. > See JCR-1184 for a test for this problem (run it with copyWhenReading=false). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1388) Jackrabbit does not allow concurrent reads to the data store if copyWhenReading=false
[ https://issues.apache.org/jira/browse/JCR-1388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Esteban Franqueiro updated JCR-1388: Attachment: (was: JCR-1388-datastore-concurrent-reads.9.patch) > Jackrabbit does not allow concurrent reads to the data store if > copyWhenReading=false > - > > Key: JCR-1388 > URL: https://issues.apache.org/jira/browse/JCR-1388 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-core >Affects Versions: 1.4 > Environment: WinXP x64, Eclipse, remote SQL Server 2005 >Reporter: Esteban Franqueiro > Attachments: JCR-1388-datastore-concurrent-reads.10.patch, > JCR-1388-datastore-concurrent-reads.2.patch, > JCR-1388-datastore-concurrent-reads.4.patch, > JCR-1388-datastore-concurrent-reads.8.patch, > JCR-1388-datastore-concurrent-reads.patch, TestTwoGetStreams.java > > > Jackrabbit does not allow concurrent reads to the data store if > copyWhenReading=false, even if maxConnections>1. > See JCR-1184 for a test for this problem (run it with copyWhenReading=false). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1388) Jackrabbit does not allow concurrent reads to the data store if copyWhenReading=false
[ https://issues.apache.org/jira/browse/JCR-1388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Esteban Franqueiro updated JCR-1388: Attachment: JCR-1388-datastore-concurrent-reads.9.patch > As I wrote before, I suggest you use Checkstyle so that you can find such > problems yourself. I'm using it, but I missed those. > What is the reason for the following code? > ... > Why do you close i1 and i2 twice? Why do you check for null? Oops my mistake. Fixed that. I left the try/catch calls, so that it logs the exception. Should I re-throw it? > Jackrabbit does not allow concurrent reads to the data store if > copyWhenReading=false > - > > Key: JCR-1388 > URL: https://issues.apache.org/jira/browse/JCR-1388 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-core >Affects Versions: 1.4 > Environment: WinXP x64, Eclipse, remote SQL Server 2005 >Reporter: Esteban Franqueiro > Attachments: JCR-1388-datastore-concurrent-reads.2.patch, > JCR-1388-datastore-concurrent-reads.4.patch, > JCR-1388-datastore-concurrent-reads.8.patch, > JCR-1388-datastore-concurrent-reads.9.patch, > JCR-1388-datastore-concurrent-reads.patch, TestTwoGetStreams.java > > > Jackrabbit does not allow concurrent reads to the data store if > copyWhenReading=false, even if maxConnections>1. > See JCR-1184 for a test for this problem (run it with copyWhenReading=false). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1388) Jackrabbit does not allow concurrent reads to the data store if copyWhenReading=false
[ https://issues.apache.org/jira/browse/JCR-1388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Esteban Franqueiro updated JCR-1388: Attachment: (was: TestTwoGetStreams.java) > Jackrabbit does not allow concurrent reads to the data store if > copyWhenReading=false > - > > Key: JCR-1388 > URL: https://issues.apache.org/jira/browse/JCR-1388 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-core >Affects Versions: 1.4 > Environment: WinXP x64, Eclipse, remote SQL Server 2005 >Reporter: Esteban Franqueiro > Attachments: JCR-1388-datastore-concurrent-reads.2.patch, > JCR-1388-datastore-concurrent-reads.4.patch, > JCR-1388-datastore-concurrent-reads.8.patch, > JCR-1388-datastore-concurrent-reads.patch, TestTwoGetStreams.java > > > Jackrabbit does not allow concurrent reads to the data store if > copyWhenReading=false, even if maxConnections>1. > See JCR-1184 for a test for this problem (run it with copyWhenReading=false). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1388) Jackrabbit does not allow concurrent reads to the data store if copyWhenReading=false
[ https://issues.apache.org/jira/browse/JCR-1388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Esteban Franqueiro updated JCR-1388: Attachment: TestTwoGetStreams.java JCR-1388-datastore-concurrent-reads.8.patch Here's a new version. I removed the synchronization from DbInputStream. I'm also posting a new version of the test, and the previous, fixed, version in the patch. Regards > Jackrabbit does not allow concurrent reads to the data store if > copyWhenReading=false > - > > Key: JCR-1388 > URL: https://issues.apache.org/jira/browse/JCR-1388 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-core >Affects Versions: 1.4 > Environment: WinXP x64, Eclipse, remote SQL Server 2005 >Reporter: Esteban Franqueiro > Attachments: JCR-1388-datastore-concurrent-reads.2.patch, > JCR-1388-datastore-concurrent-reads.4.patch, > JCR-1388-datastore-concurrent-reads.8.patch, > JCR-1388-datastore-concurrent-reads.patch, TestTwoGetStreams.java, > TestTwoGetStreams.java > > > Jackrabbit does not allow concurrent reads to the data store if > copyWhenReading=false, even if maxConnections>1. > See JCR-1184 for a test for this problem (run it with copyWhenReading=false). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1456) Database connection pooling
[ https://issues.apache.org/jira/browse/JCR-1456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12575451#action_12575451 ] Esteban Franqueiro commented on JCR-1456: - Is it possible to have, in those areas, the same problem reported in JCR-1388? The idea is to use a pool package or to build our own? > Database connection pooling > --- > > Key: JCR-1456 > URL: https://issues.apache.org/jira/browse/JCR-1456 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-core >Reporter: Jukka Zitting > Fix For: 1.5 > > > Jackrabbit should use database connection pools instead of a single > connection per persistence manager, cluster journal, or database data store. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1437) add framework for performance tests
[ https://issues.apache.org/jira/browse/JCR-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12575368#action_12575368 ] Esteban Franqueiro commented on JCR-1437: - I was under the impression that we would be testing performance/scalability/etc., not compliance. Am I wrong? > add framework for performance tests > --- > > Key: JCR-1437 > URL: https://issues.apache.org/jira/browse/JCR-1437 > Project: Jackrabbit > Issue Type: New Feature > Components: jackrabbit-jcr-tests >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Attachments: JCR-1437-2.patch, JCR-1437.patch, perftest.patch > > > Add a test suite for running various kinds of performance tests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1437) add framework for performance tests
[ https://issues.apache.org/jira/browse/JCR-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12575357#action_12575357 ] Esteban Franqueiro commented on JCR-1437: - Hi. I would use jackrabbit-benchmark for the package name, since it's not JCR (API) related. Regards > add framework for performance tests > --- > > Key: JCR-1437 > URL: https://issues.apache.org/jira/browse/JCR-1437 > Project: Jackrabbit > Issue Type: New Feature > Components: jackrabbit-jcr-tests >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Attachments: JCR-1437-2.patch, JCR-1437.patch, perftest.patch > > > Add a test suite for running various kinds of performance tests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1388) Jackrabbit does not allow concurrent reads to the data store if copyWhenReading=false
[ https://issues.apache.org/jira/browse/JCR-1388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Esteban Franqueiro updated JCR-1388: Attachment: JCR-1388-datastore-concurrent-reads.4.patch Ok, here's a new take at it. I hope I resolved all the issues you pointed out. > DbInputStream.mark and reset are synchronized, but nothing else in this > class, why? I followed the pattern used in InputStream and FilterInputStream. Regarding the finalizer, I removed it, but I think that it depends on what your position is regarding improper use of the stream. If the policy is to protect against that kind of mistake or to let it happen so that in the end the user has to fix it's application. > Jackrabbit does not allow concurrent reads to the data store if > copyWhenReading=false > - > > Key: JCR-1388 > URL: https://issues.apache.org/jira/browse/JCR-1388 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-core >Affects Versions: 1.4 > Environment: WinXP x64, Eclipse, remote SQL Server 2005 >Reporter: Esteban Franqueiro > Attachments: JCR-1388-datastore-concurrent-reads.2.patch, > JCR-1388-datastore-concurrent-reads.4.patch, > JCR-1388-datastore-concurrent-reads.patch, TestTwoGetStreams.java > > > Jackrabbit does not allow concurrent reads to the data store if > copyWhenReading=false, even if maxConnections>1. > See JCR-1184 for a test for this problem (run it with copyWhenReading=false). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1388) Jackrabbit does not allow concurrent reads to the data store if copyWhenReading=false
[ https://issues.apache.org/jira/browse/JCR-1388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Esteban Franqueiro updated JCR-1388: Attachment: TestTwoGetStreams.java JCR-1388-datastore-concurrent-reads.2.patch The new patch corrects the issues pointed by Thomas. The test passes with the patch applied, copyWhenReading=false and storeStream=-1. Without the patch, the test fails with the same conditions. > Jackrabbit does not allow concurrent reads to the data store if > copyWhenReading=false > - > > Key: JCR-1388 > URL: https://issues.apache.org/jira/browse/JCR-1388 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-core >Affects Versions: 1.4 > Environment: WinXP x64, Eclipse, remote SQL Server 2005 >Reporter: Esteban Franqueiro > Attachments: JCR-1388-datastore-concurrent-reads.2.patch, > JCR-1388-datastore-concurrent-reads.patch, TestTwoGetStreams.java > > > Jackrabbit does not allow concurrent reads to the data store if > copyWhenReading=false, even if maxConnections>1. > See JCR-1184 for a test for this problem (run it with copyWhenReading=false). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1388) Jackrabbit does not allow concurrent reads to the data store if copyWhenReading=false
[
https://issues.apache.org/jira/browse/JCR-1388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12573815#action_12573815
]
Esteban Franqueiro commented on JCR-1388:
-
Hi.
> I have a few remarks, first about the source code 'style'. I use Eclipse and
> the Checkstyle plugin, this should find most issues:
> - you should use spaces instead of tabs
> - return doesn't required brackets: return(false) should be changed to return
> false
> - catch (IOException e) {} should at least have a remark, but it's better to
> log the exception (with stack trace)
> - you need to replace the file file headers
> - use '} else {', '} finally {' and '} catch (Exception e) {' as in the Sun
> Java coding guidelines
> - Don't declare all variables at the start of the method as in C. Declare
> them when / just before using them
> (for example, getResourceAsReader(), reader; there are others
> - Review the Javadocs rules (add comments, use the @param, @return tags)
> - Only use this. when required
Fixed all of those I think.
> Some other remarks:
> - I didn't see any test cases - please add one
> - Are prepareSchemaObjectPrefix and getResourceAsReader used somewhere? Don't
> add unused methods
Removed them.
> - close() methods easting exceptions should be called closeSilently()
Renamed them.
> - You have removed the SQL statement remark, why? // SELECT ID, DATA FROM
> DATASTORE WHERE ID = ?
Because I deleted the entire method.
> - If you are removing code, remove the lines, don't remark them
> (+//lastModified = ...)
> - getDatabaseResources, boolean success is always true
> - You hare remarked "lastModified = store.touch(getIdentifier(),
> lastModified)", why?
Fixed those.
> - Don't swallow exceptions (use IOException.initCause in
> DbInputStream.getStream())
> - Synchronization is very inconsistent (DbInputStream)
In what sense? The DbInputStream is not supposed to be used from multiple
threads, so I only synchronized the methods that are already synchronized in
InputStream.
I'll attach the new patch and test.
Regards.
> Jackrabbit does not allow concurrent reads to the data store if
> copyWhenReading=false
> -
>
> Key: JCR-1388
> URL: https://issues.apache.org/jira/browse/JCR-1388
> Project: Jackrabbit
> Issue Type: Improvement
> Components: jackrabbit-core
>Affects Versions: 1.4
> Environment: WinXP x64, Eclipse, remote SQL Server 2005
>Reporter: Esteban Franqueiro
> Attachments: JCR-1388-datastore-concurrent-reads.patch
>
>
> Jackrabbit does not allow concurrent reads to the data store if
> copyWhenReading=false, even if maxConnections>1.
> See JCR-1184 for a test for this problem (run it with copyWhenReading=false).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1437) add framework for performance tests
[ https://issues.apache.org/jira/browse/JCR-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12573424#action_12573424 ] Esteban Franqueiro commented on JCR-1437: - I think that some of the concurrency tests we have should be moved here, because they're mostly about performance. I also think that this is a great idea, and that finally we'll get a consistent and common way to compare different approaches to do things. > add framework for performance tests > --- > > Key: JCR-1437 > URL: https://issues.apache.org/jira/browse/JCR-1437 > Project: Jackrabbit > Issue Type: New Feature > Components: jackrabbit-jcr-tests >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Attachments: perftest.patch > > > Add a test suite for running various kinds of performance tests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1388) Jackrabbit does not allow concurrent reads to the data store if copyWhenReading=false
[ https://issues.apache.org/jira/browse/JCR-1388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12573307#action_12573307 ] Esteban Franqueiro commented on JCR-1388: - Hi. Did anyone take a look at this patch? Regards > Jackrabbit does not allow concurrent reads to the data store if > copyWhenReading=false > - > > Key: JCR-1388 > URL: https://issues.apache.org/jira/browse/JCR-1388 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-core >Affects Versions: 1.4 > Environment: WinXP x64, Eclipse, remote SQL Server 2005 >Reporter: Esteban Franqueiro > Attachments: JCR-1388-datastore-concurrent-reads.patch > > > Jackrabbit does not allow concurrent reads to the data store if > copyWhenReading=false, even if maxConnections>1. > See JCR-1184 for a test for this problem (run it with copyWhenReading=false). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1395) Use Commons IO 1.4
[ https://issues.apache.org/jira/browse/JCR-1395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Esteban Franqueiro updated JCR-1395: Attachment: JCR-1395-closers.patch Same patch, but I deleted some methods but did not replace them. Also added some javadocs. > Use Commons IO 1.4 > -- > > Key: JCR-1395 > URL: https://issues.apache.org/jira/browse/JCR-1395 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-core >Reporter: Jukka Zitting >Priority: Minor > Fix For: 1.5 > > Attachments: io.patch, JCR-1395-closers.patch > > > Commons IO contains a number of utility classes and methods for working with > files and streams. Many of those utilities would be quite useful in > Jackrabbit, so I'd like to introduce commons-io 1.4 as a dependency to > jackrabbit-core. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1395) Use Commons IO 1.4
[ https://issues.apache.org/jira/browse/JCR-1395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Esteban Franqueiro updated JCR-1395: Attachment: (was: closers.patch) > Use Commons IO 1.4 > -- > > Key: JCR-1395 > URL: https://issues.apache.org/jira/browse/JCR-1395 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-core >Reporter: Jukka Zitting >Priority: Minor > Fix For: 1.5 > > Attachments: io.patch, JCR-1395-closers.patch > > > Commons IO contains a number of utility classes and methods for working with > files and streams. Many of those utilities would be quite useful in > Jackrabbit, so I'd like to introduce commons-io 1.4 as a dependency to > jackrabbit-core. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1395) Use Commons IO 1.4
[ https://issues.apache.org/jira/browse/JCR-1395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Esteban Franqueiro updated JCR-1395: Attachment: closers.patch This patch replaces the calls to closing funcions and explicit calls to close() with a call to new unified closing functions. This is juast a PoC, and if there's interest in pursuing this way, I can continue working on it. WDYT? > Use Commons IO 1.4 > -- > > Key: JCR-1395 > URL: https://issues.apache.org/jira/browse/JCR-1395 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-core >Reporter: Jukka Zitting >Priority: Minor > Fix For: 1.5 > > Attachments: closers.patch, io.patch > > > Commons IO contains a number of utility classes and methods for working with > files and streams. Many of those utilities would be quite useful in > Jackrabbit, so I'd like to introduce commons-io 1.4 as a dependency to > jackrabbit-core. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1395) Use Commons IO 1.4
[ https://issues.apache.org/jira/browse/JCR-1395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12571038#action_12571038 ] Esteban Franqueiro commented on JCR-1395: - I agree with Thomas that we don't do a good job with maintaining the utility classes, and also we have som duplicated code (eg, in BundleDbPersistenceManager there's a closeResultSet() method, and also a few direct calls to ResultSet.close(). The same happens with InputStream's. I think we should have a common DbHelper with methods like close(ResultSet), close(Statement), close(Connection/ConnectionRecoveryManager) (that's because I don't like to call methods closeResultSet or closeSilently since it's obvious by the signature). Like that, I think we should have a common StreamHelper. I don't have a formed opinion on whether we should maintain them or if we should use another component, but we should definitely have one or the other. I'll try to write a DbHelper class and patch for this. Still, I think that some of examples mentioned by Jukka are actually very useful. In particular, I think that #5 would be very useful for the DbDataStore and the DbResources/DbInputStream I posted in JCR-1388. > Use Commons IO 1.4 > -- > > Key: JCR-1395 > URL: https://issues.apache.org/jira/browse/JCR-1395 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-core >Reporter: Jukka Zitting >Priority: Minor > Fix For: 1.5 > > Attachments: io.patch > > > Commons IO contains a number of utility classes and methods for working with > files and streams. Many of those utilities would be quite useful in > Jackrabbit, so I'd like to introduce commons-io 1.4 as a dependency to > jackrabbit-core. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1388) Jackrabbit does not allow concurrent reads to the data store if copyWhenReading=false
[ https://issues.apache.org/jira/browse/JCR-1388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Esteban Franqueiro updated JCR-1388: Attachment: JCR-1388-datastore-concurrent-reads.patch This patch addresses the issue by provinding a wrapper input stream that encapsulates the database resources, and not returning the connection to the pool until the stream is consumed/closed. > Jackrabbit does not allow concurrent reads to the data store if > copyWhenReading=false > - > > Key: JCR-1388 > URL: https://issues.apache.org/jira/browse/JCR-1388 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-core >Affects Versions: 1.4 > Environment: WinXP x64, Eclipse, remote SQL Server 2005 >Reporter: Esteban Franqueiro > Attachments: JCR-1388-datastore-concurrent-reads.patch > > > Jackrabbit does not allow concurrent reads to the data store if > copyWhenReading=false, even if maxConnections>1. > See JCR-1184 for a test for this problem (run it with copyWhenReading=false). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1388) Jackrabbit does not allow concurrent reads to the data store if copyWhenReading=false
Jackrabbit does not allow concurrent reads to the data store if copyWhenReading=false - Key: JCR-1388 URL: https://issues.apache.org/jira/browse/JCR-1388 Project: Jackrabbit Issue Type: Improvement Components: jackrabbit-core Affects Versions: 1.4 Environment: WinXP x64, Eclipse, remote SQL Server 2005 Reporter: Esteban Franqueiro Jackrabbit does not allow concurrent reads to the data store if copyWhenReading=false, even if maxConnections>1. See JCR-1184 for a test for this problem (run it with copyWhenReading=false). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1187) Asking a property twice for it's stream returns the same stream instance
[ https://issues.apache.org/jira/browse/JCR-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Esteban Franqueiro updated JCR-1187: Attachment: (was: TestTwoGetStreams.java) > Asking a property twice for it's stream returns the same stream instance > > > Key: JCR-1187 > URL: https://issues.apache.org/jira/browse/JCR-1187 > Project: Jackrabbit > Issue Type: Bug > Components: jackrabbit-core >Reporter: Esteban Franqueiro > Attachments: DataStoreTestUtils.java, TestTwoGetStreams.java > > > If you ask a property stored in the database data store (JCR-1154) for it's > associated stream twice, the stream instance returned is the same. This > behavior is not consistent with the file data store, which returns a > different stream instance each time Property.getStream() is called. > I'm attaching a test case wich demostrates the issue. > We're working on this and have a potencial fix for it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1187) Asking a property twice for it's stream returns the same stream instance
[ https://issues.apache.org/jira/browse/JCR-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Esteban Franqueiro updated JCR-1187: Attachment: (was: DataStoreTestUtils.java) > Asking a property twice for it's stream returns the same stream instance > > > Key: JCR-1187 > URL: https://issues.apache.org/jira/browse/JCR-1187 > Project: Jackrabbit > Issue Type: Bug > Components: jackrabbit-core >Reporter: Esteban Franqueiro > Attachments: DataStoreTestUtils.java, TestTwoGetStreams.java > > > If you ask a property stored in the database data store (JCR-1154) for it's > associated stream twice, the stream instance returned is the same. This > behavior is not consistent with the file data store, which returns a > different stream instance each time Property.getStream() is called. > I'm attaching a test case wich demostrates the issue. > We're working on this and have a potencial fix for it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1187) Asking a property twice for it's stream returns the same stream instance
[ https://issues.apache.org/jira/browse/JCR-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Esteban Franqueiro updated JCR-1187: Attachment: TestTwoGetStreams.java DataStoreTestUtils.java This are updated versions of the same previous tests. > Asking a property twice for it's stream returns the same stream instance > > > Key: JCR-1187 > URL: https://issues.apache.org/jira/browse/JCR-1187 > Project: Jackrabbit > Issue Type: Bug > Components: jackrabbit-core >Reporter: Esteban Franqueiro > Attachments: DataStoreTestUtils.java, TestTwoGetStreams.java > > > If you ask a property stored in the database data store (JCR-1154) for it's > associated stream twice, the stream instance returned is the same. This > behavior is not consistent with the file data store, which returns a > different stream instance each time Property.getStream() is called. > I'm attaching a test case wich demostrates the issue. > We're working on this and have a potencial fix for it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1154) Database Data Store
[ https://issues.apache.org/jira/browse/JCR-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Esteban Franqueiro updated JCR-1154: Attachment: datastore-concurrent-reads.zip The attachment contains a test class for the issue I reported in [1] and a helper class it depends on. Also includes a patch that corrects this issue by allowing pooled connections to remain open until the streams they're serving are closed. [1] http://mail-archives.apache.org/mod_mbox/jackrabbit-dev/200802.mbox/browser > Database Data Store > --- > > Key: JCR-1154 > URL: https://issues.apache.org/jira/browse/JCR-1154 > Project: Jackrabbit > Issue Type: New Feature > Components: jackrabbit-core >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Blocker > Fix For: 1.4 > > Attachments: datastore-concurrent-reads.zip, jr-1.3.1-bea.zip > > > We want to have a database backed data store implementation. > An implementation using files is already available as part of JCR-926. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1154) Database Data Store
[ https://issues.apache.org/jira/browse/JCR-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12565754#action_12565754 ] Esteban Franqueiro commented on JCR-1154: - The following javadoc comment should be removed from the DbDataStore class: * A three level directory structure is used to avoid placing too many * files in a single directory. The chosen structure is designed to scale * up to billions of distinct records. > Database Data Store > --- > > Key: JCR-1154 > URL: https://issues.apache.org/jira/browse/JCR-1154 > Project: Jackrabbit > Issue Type: New Feature > Components: jackrabbit-core >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Blocker > Fix For: 1.4 > > Attachments: jr-1.3.1-bea.zip > > > We want to have a database backed data store implementation. > An implementation using files is already available as part of JCR-926. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1306) Reduce number of different repository.xml present with jackrabbit-core
[ https://issues.apache.org/jira/browse/JCR-1306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12564019#action_12564019 ] Esteban Franqueiro commented on JCR-1306: - I agree with Jukka in that we should get rid of all config files that don't have a sound reason to stay where they are. Regarding to Stefan's comment, I think that there could be a new directory in svn called examples or something like that, where we can put different configuration examples. > Reduce number of different repository.xml present with jackrabbit-core > -- > > Key: JCR-1306 > URL: https://issues.apache.org/jira/browse/JCR-1306 > Project: Jackrabbit > Issue Type: Improvement > Components: config >Reporter: angela >Priority: Minor > > while taking a look at the repository configuration and the related > test-cases, i saw that there are quite some repository.xml files around... > which i think is a bit confusion and probably hard to maintain once we make > changes to the config. > i would to suggest to consolidate that and - if possible - get rid of some of > them. > if we can't i would suggest to put some comment in every of the different > configuration files indicating > what they are used for. > from what i've seen so far (still missing complete overview) > 1) > http://svn.apache.org/repos/asf/jackrabbit/trunk/jackrabbit-core/src/main/config/repository.xml > Current comment: > Usage: ?? > 2) > http://svn.apache.org/repos/asf/jackrabbit/trunk/jackrabbit-core/src/main/resources/org/apache/jackrabbit/core/test-repository.xml >current comment: - >Used as repository configuration in > org.apache.jackrabbit.core.TestRepository.java > > 3) > http://svn.apache.org/repos/asf/jackrabbit/trunk/jackrabbit-core/src/main/resources/org/apache/jackrabbit/core/repository.xml > >current comment: >Used by org.apache.jackrabbit.core.config.RepositoryConfigTest.java in > order to create another repository.xml >under target/test-repository.xml. a bit confusing given the fact, that a > test-repository.xml exists as well. I would >suggest to rename the REPOSITORY_XML constant in RepositoryConfigTest. > 4) > http://svn.apache.org/repos/asf/jackrabbit/trunk/jackrabbit-core/src/test/repository/repository.xml >current comment: >Usage: i assume, that is the one referenced in > test/resources/repositoryStubImpl.properties > 5) > http://svn.apache.org/repos/asf/jackrabbit/trunk/jackrabbit-core/src/test/resources/org/apache/jackrabbit/core/config/repository.xml >current comment: >Usage: ?? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1330) repository.xml DTD doesn't allow element
[ https://issues.apache.org/jira/browse/JCR-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561096#action_12561096 ] Esteban Franqueiro commented on JCR-1330: - Shouldn't the org.jackrabbit.useDataStore system property be documented in the wiki too? Because although in RepositoryImpl's constructor it is asserted true in case the data store config is not null, in InternalValue it's used regardless of the case. So if the data store is not configured but the property is true (which is it's default value) then the processing in InternalValue is wrong. IMHO, this property should be removed altogether. Regards > repository.xml DTD doesn't allow element > > > Key: JCR-1330 > URL: https://issues.apache.org/jira/browse/JCR-1330 > Project: Jackrabbit > Issue Type: Bug > Components: config, docs >Affects Versions: 1.4 >Reporter: Eric Norman >Priority: Minor > Attachments: repository-1.4.dtd > > > The repository.xml DTD at http://jackrabbit.apache.org/dtd/repository-1.4.dtd > conflicts with the instructions in the wiki page at > http://wiki.apache.org/jackrabbit/DataStore > Adding the element as specified in the wiki page violates the DTD. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1284) Use bundle persistence in default configuration
[ https://issues.apache.org/jira/browse/JCR-1284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12555344#action_12555344 ] Esteban Franqueiro commented on JCR-1284: - Is this going to be fixed anytime soon? Perhaps for 1.4? :) For now, where's the main repository.xml file? It's the one in core/src/main/config? > Use bundle persistence in default configuration > --- > > Key: JCR-1284 > URL: https://issues.apache.org/jira/browse/JCR-1284 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-core, jackrabbit-webapp >Reporter: Jukka Zitting >Assignee: Jukka Zitting >Priority: Minor > Fix For: 1.4 > > > The default repository configuration files in jackrabbit-core and -webapp > still use the old simple database persistence. They should be updated to use > bundle persistence in the 1.4 release. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1284) Use bundle persistence in default configuration
[ https://issues.apache.org/jira/browse/JCR-1284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12555299#action_12555299 ] Esteban Franqueiro commented on JCR-1284: - Hi Jukka. I asked in the lists some time ago why we have so many repository.xml files and which one is for what. I think now is a good time to ask again :) Regards. > Use bundle persistence in default configuration > --- > > Key: JCR-1284 > URL: https://issues.apache.org/jira/browse/JCR-1284 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-core, jackrabbit-webapp >Reporter: Jukka Zitting >Assignee: Jukka Zitting >Priority: Minor > Fix For: 1.4 > > > The default repository configuration files in jackrabbit-core and -webapp > still use the old simple database persistence. They should be updated to use > bundle persistence in the 1.4 release. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1250) When adding a large (100MB) binary to the DbDataStore, it fails with an insufficient memory exception
[
https://issues.apache.org/jira/browse/JCR-1250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12554002
]
Esteban Franqueiro commented on JCR-1250:
-
I'm just reporting that I run BigBinaryTest with the default ISM locking, and
it failed.
Back to profilers, I have a license of JProfiler here, so I'll see which one is
easier. Still, I think that adding some advice to the site/wiki on how to
profile Jackrabbit would be useful.
Regards.
> When adding a large (100MB) binary to the DbDataStore, it fails with an
> insufficient memory exception
> -
>
> Key: JCR-1250
> URL: https://issues.apache.org/jira/browse/JCR-1250
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-core
> Environment: Windows XP x64 client, SQL Server 2005
>Reporter: Esteban Franqueiro
>Assignee: Thomas Mueller
> Fix For: 1.4
>
> Attachments: BigBinaryTest.java, TestLargeObject.java
>
>
> Attached is a small test case. It fails during save(). I think this is
> related to what I mentioned in
> http://mail-archives.apache.org/mod_mbox/jackrabbit-dev/200711.mbox/[EMAIL
> PROTECTED]
> The full stacktrace is the following:
> javax.jcr.RepositoryException: /: unable to update item.: failed to write
> property state: cafebabe-cafe-babe-cafe-babecafebabe/{}bin: failed to write
> property state: cafebabe-cafe-babe-cafe-babecafebabe/{}bin
> at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1252)
> at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:858)
> at
> org.apache.jackrabbit.core.data.BigBinaryTest.testBigBinary(BigBinaryTest.java:16)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at junit.framework.TestCase.runTest(TestCase.java:154)
> at junit.framework.TestCase.runBare(TestCase.java:127)
> at junit.framework.TestResult$1.protect(TestResult.java:106)
> at junit.framework.TestResult.runProtected(TestResult.java:124)
> at junit.framework.TestResult.run(TestResult.java:109)
> at junit.framework.TestCase.run(TestCase.java:118)
> at
> org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:404)
> at junit.framework.TestSuite.runTest(TestSuite.java:208)
> at junit.framework.TestSuite.run(TestSuite.java:203)
> at
> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128)
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
> Caused by: org.apache.jackrabbit.core.state.ItemStateException: failed to
> write property state: cafebabe-cafe-babe-cafe-babecafebabe/{}bin
> at
> org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.store(DatabasePersistenceManager.java:487)
> at
> org.apache.jackrabbit.core.persistence.AbstractPersistenceManager.store(AbstractPersistenceManager.java:75)
> at
> org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.store(DatabasePersistenceManager.java:282)
> at
> org.apache.jackrabbit.core.state.SharedItemStateManager$Update.end(SharedItemStateManager.java:687)
> at
> org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:856)
> at
> org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:324)
> at
> org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:313)
> at
> org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:300)
> at
> org.apache.jackrabbit.core.state.SessionItemStateManager.update(SessionItemStateManager.java:306)
> at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1244)
> ... 21 more
> Caused by: org.apache.jackrabbit.core.data.DataStoreException: Can not read
> identifier a2ada2d96d0b05214288efa03be9005a5bb98c9b: Memoria insuficiente.
> Utilice cursores del servidor para result sets grandes:Java heap space.
> Tamaño de result set:104.857.723. Tamaño memoria total JVM:66.650.112.:
> Memor
[jira] Commented: (JCR-1250) When adding a large (100MB) binary to the DbDataStore, it fails with an insufficient memory exception
[
https://issues.apache.org/jira/browse/JCR-1250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553987
]
Esteban Franqueiro commented on JCR-1250:
-
Hi Thomas.
My guess is that there is some overhead somewhere, but it's strange that using
the same test we get different results. I'm using the FGLS, so I'll try with
the default.
I do know YJP, but never used it before. Still, I'll see if I can run it. Do
you have any advice on how to profile Jackrabbit?
Regards.
> When adding a large (100MB) binary to the DbDataStore, it fails with an
> insufficient memory exception
> -
>
> Key: JCR-1250
> URL: https://issues.apache.org/jira/browse/JCR-1250
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-core
> Environment: Windows XP x64 client, SQL Server 2005
>Reporter: Esteban Franqueiro
>Assignee: Thomas Mueller
> Fix For: 1.4
>
> Attachments: BigBinaryTest.java, TestLargeObject.java
>
>
> Attached is a small test case. It fails during save(). I think this is
> related to what I mentioned in
> http://mail-archives.apache.org/mod_mbox/jackrabbit-dev/200711.mbox/[EMAIL
> PROTECTED]
> The full stacktrace is the following:
> javax.jcr.RepositoryException: /: unable to update item.: failed to write
> property state: cafebabe-cafe-babe-cafe-babecafebabe/{}bin: failed to write
> property state: cafebabe-cafe-babe-cafe-babecafebabe/{}bin
> at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1252)
> at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:858)
> at
> org.apache.jackrabbit.core.data.BigBinaryTest.testBigBinary(BigBinaryTest.java:16)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at junit.framework.TestCase.runTest(TestCase.java:154)
> at junit.framework.TestCase.runBare(TestCase.java:127)
> at junit.framework.TestResult$1.protect(TestResult.java:106)
> at junit.framework.TestResult.runProtected(TestResult.java:124)
> at junit.framework.TestResult.run(TestResult.java:109)
> at junit.framework.TestCase.run(TestCase.java:118)
> at
> org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:404)
> at junit.framework.TestSuite.runTest(TestSuite.java:208)
> at junit.framework.TestSuite.run(TestSuite.java:203)
> at
> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128)
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
> Caused by: org.apache.jackrabbit.core.state.ItemStateException: failed to
> write property state: cafebabe-cafe-babe-cafe-babecafebabe/{}bin
> at
> org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.store(DatabasePersistenceManager.java:487)
> at
> org.apache.jackrabbit.core.persistence.AbstractPersistenceManager.store(AbstractPersistenceManager.java:75)
> at
> org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.store(DatabasePersistenceManager.java:282)
> at
> org.apache.jackrabbit.core.state.SharedItemStateManager$Update.end(SharedItemStateManager.java:687)
> at
> org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:856)
> at
> org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:324)
> at
> org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:313)
> at
> org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:300)
> at
> org.apache.jackrabbit.core.state.SessionItemStateManager.update(SessionItemStateManager.java:306)
> at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1244)
> ... 21 more
> Caused by: org.apache.jackrabbit.core.data.DataStoreException: Can not read
> identifier a2ada2d96d0b05214288efa03be9005a5bb98c9b: Memoria insuficiente.
> Utilice cursores del servidor para result sets grandes:Java heap space.
> Tamaño de result set:104.857.723. Tamaño memoria tot
[jira] Commented: (JCR-1250) When adding a large (100MB) binary to the DbDataStore, it fails with an insufficient memory exception
[
https://issues.apache.org/jira/browse/JCR-1250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553705
]
Esteban Franqueiro commented on JCR-1250:
-
Here are my results.
url: jdbc:sqlserver://et:1433;databaseName=repotest;responseBuffering=adaptive
meta.url:
jdbc:sqlserver://et:1433;responseBuffering=adaptive;encrypt=false;databaseName=repotest;selectMethod=direct;trustServerCertificate=false;lastUpdateCount=true;
name: Microsoft SQL Server
version: 9.00.1399
driver name: Microsoft SQL Server 2005 JDBC Driver
driver version: 1.2.2828.100
storing data...
selecting data...
length: 104857600 expected: 104857600
reading data...
done
> When adding a large (100MB) binary to the DbDataStore, it fails with an
> insufficient memory exception
> -
>
> Key: JCR-1250
> URL: https://issues.apache.org/jira/browse/JCR-1250
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-core
> Environment: Windows XP x64 client, SQL Server 2005
>Reporter: Esteban Franqueiro
>Assignee: Thomas Mueller
> Fix For: 1.4
>
> Attachments: BigBinaryTest.java, TestLargeObject.java
>
>
> Attached is a small test case. It fails during save(). I think this is
> related to what I mentioned in
> http://mail-archives.apache.org/mod_mbox/jackrabbit-dev/200711.mbox/[EMAIL
> PROTECTED]
> The full stacktrace is the following:
> javax.jcr.RepositoryException: /: unable to update item.: failed to write
> property state: cafebabe-cafe-babe-cafe-babecafebabe/{}bin: failed to write
> property state: cafebabe-cafe-babe-cafe-babecafebabe/{}bin
> at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1252)
> at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:858)
> at
> org.apache.jackrabbit.core.data.BigBinaryTest.testBigBinary(BigBinaryTest.java:16)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at junit.framework.TestCase.runTest(TestCase.java:154)
> at junit.framework.TestCase.runBare(TestCase.java:127)
> at junit.framework.TestResult$1.protect(TestResult.java:106)
> at junit.framework.TestResult.runProtected(TestResult.java:124)
> at junit.framework.TestResult.run(TestResult.java:109)
> at junit.framework.TestCase.run(TestCase.java:118)
> at
> org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:404)
> at junit.framework.TestSuite.runTest(TestSuite.java:208)
> at junit.framework.TestSuite.run(TestSuite.java:203)
> at
> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128)
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
> Caused by: org.apache.jackrabbit.core.state.ItemStateException: failed to
> write property state: cafebabe-cafe-babe-cafe-babecafebabe/{}bin
> at
> org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.store(DatabasePersistenceManager.java:487)
> at
> org.apache.jackrabbit.core.persistence.AbstractPersistenceManager.store(AbstractPersistenceManager.java:75)
> at
> org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.store(DatabasePersistenceManager.java:282)
> at
> org.apache.jackrabbit.core.state.SharedItemStateManager$Update.end(SharedItemStateManager.java:687)
> at
> org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:856)
> at
> org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:324)
> at
> org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:313)
> at
> org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:300)
> at
> org.apache.jackrabbit.core.state.SessionItemStateManager.update(SessionItemStateManager.java:306)
> at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1244)
> ... 21 more
> Caused by: org.apache.jackrabbit.core.data.DataStoreException: Can not read
> identifier a2ada2d96d0b05214288ef
[jira] Commented: (JCR-73) Improve Javadoc documentation
[ https://issues.apache.org/jira/browse/JCR-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553446 ] Esteban Franqueiro commented on JCR-73: --- The javadoc in org.apache.jackrabbit.name.NamespaceResolver deprectes the class and says to use the same class instead. Shouldn't these classes be made like the persistence managers, and extend the classes that supercede them? > Improve Javadoc documentation > - > > Key: JCR-73 > URL: https://issues.apache.org/jira/browse/JCR-73 > Project: Jackrabbit > Issue Type: Improvement > Components: docs >Reporter: Jukka Zitting >Priority: Minor > Fix For: none > > > This is an ongoing meta-issue for improving the state of documentation in > Jackrabbit. After a long history of following the maturing JSR 170 > specification, the Jackrabbit codebase contains many parts that would benefit > from better documentation. This issue is a call to arms for a community > effort to improve the Javadoc documentation of Jackrabbit. > By this issue, you have an open mandate to improve the Javadoc documentation > of any relatively stable part of Jackrabbit (no major changes during the last > few weeks). You are free to contribute even partial and cursory > documentation. Just follow the instructions below! > Instructions for non-committers: > If you want to help in improving the Javadoc documentation of Jackrabbit, > please send your improvements as attachments to this issue. The best way to > do this is to first check out the Jackrabbit source tree using anonymous > Subversion, then make the Javadoc improvements you like, and finally use "svn > diff" to generate a diff file that contains all your changes. You can then > attach the diff file to this issue by following the "Attach file" link in the > sidebar. Please remember to grant us the rights to include your changes (use > the ASF grant option on the upload page). You may also want to write a short > summary comment about the Javadoc improvements you made. > If you want to make changes also to the Jackrabbit code, then please send > your changes to another issue. This issue is reserved only for Javadoc > improvements. > Instructions for committers: > Please label your Javadoc commit messages with the Jira key (JCR-73) of this > issue to mark the changes as document-only. This way other committers won't > need to check your changes for bugs or other unexpected side-effects. Please > follow the same guidelines also when committing Javadoc changes sent by > non-committers. > This issue should remain as an unassigned and open issue at least for now. If > this approach turns out to complicate Jira reports, then we can switch to > another mechanism for handling Javadoc improvements. In that case this issue > should be closed with a comment that explains the changes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1276) A Property and a Node Can Have the Same Name
[ https://issues.apache.org/jira/browse/JCR-1276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553419 ] Esteban Franqueiro commented on JCR-1276: - It seems that the last commit deleted some changes from previous commits. For example, SessionImpl.createDataStoreGarbageCollector(), but I think there are others. Regards. > A Property and a Node Can Have the Same Name > - > > Key: JCR-1276 > URL: https://issues.apache.org/jira/browse/JCR-1276 > Project: Jackrabbit > Issue Type: New Feature > Components: JCR 2.0 >Reporter: Stefan Guggisberg >Assignee: Stefan Guggisberg >Priority: Minor > Fix For: 2.0 > > > according to paragraph "3.3.4" of the of the JSR 283 specification (Public > Review Draft), a property and a node can have the same name. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1250) When adding a large (100MB) binary to the DbDataStore, it fails with an insufficient memory exception
[
https://issues.apache.org/jira/browse/JCR-1250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12552782
]
Esteban Franqueiro commented on JCR-1250:
-
>From jcr.log:
[main] ConnectionRecoveryManager: Database: Microsoft SQL Server / 9.00.1399
(ConnectionRecoveryManager.java, line 336)
[main] ConnectionRecoveryManager: Driver: Microsoft SQL Server 2005 JDBC Driver
/ 1.2.2828.100 (ConnectionRecoveryManager.java, line 337)
[main] DbDataStore: Using JDBC driver Microsoft SQL Server 2005 JDBC Driver
1.2.2828.100 (DbDataStore.java, line 485)
My URL:
jdbc:sqlserver://et:1433;databaseName=repotest;responseBuffering=adaptive;
> When adding a large (100MB) binary to the DbDataStore, it fails with an
> insufficient memory exception
> -
>
> Key: JCR-1250
> URL: https://issues.apache.org/jira/browse/JCR-1250
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-core
> Environment: Windows XP x64 client, SQL Server 2005
>Reporter: Esteban Franqueiro
>Assignee: Thomas Mueller
> Fix For: 1.4
>
> Attachments: BigBinaryTest.java
>
>
> Attached is a small test case. It fails during save(). I think this is
> related to what I mentioned in
> http://mail-archives.apache.org/mod_mbox/jackrabbit-dev/200711.mbox/[EMAIL
> PROTECTED]
> The full stacktrace is the following:
> javax.jcr.RepositoryException: /: unable to update item.: failed to write
> property state: cafebabe-cafe-babe-cafe-babecafebabe/{}bin: failed to write
> property state: cafebabe-cafe-babe-cafe-babecafebabe/{}bin
> at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1252)
> at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:858)
> at
> org.apache.jackrabbit.core.data.BigBinaryTest.testBigBinary(BigBinaryTest.java:16)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at junit.framework.TestCase.runTest(TestCase.java:154)
> at junit.framework.TestCase.runBare(TestCase.java:127)
> at junit.framework.TestResult$1.protect(TestResult.java:106)
> at junit.framework.TestResult.runProtected(TestResult.java:124)
> at junit.framework.TestResult.run(TestResult.java:109)
> at junit.framework.TestCase.run(TestCase.java:118)
> at
> org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:404)
> at junit.framework.TestSuite.runTest(TestSuite.java:208)
> at junit.framework.TestSuite.run(TestSuite.java:203)
> at
> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128)
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
> Caused by: org.apache.jackrabbit.core.state.ItemStateException: failed to
> write property state: cafebabe-cafe-babe-cafe-babecafebabe/{}bin
> at
> org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.store(DatabasePersistenceManager.java:487)
> at
> org.apache.jackrabbit.core.persistence.AbstractPersistenceManager.store(AbstractPersistenceManager.java:75)
> at
> org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.store(DatabasePersistenceManager.java:282)
> at
> org.apache.jackrabbit.core.state.SharedItemStateManager$Update.end(SharedItemStateManager.java:687)
> at
> org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:856)
> at
> org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:324)
> at
> org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:313)
> at
> org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:300)
> at
> org.apache.jackrabbit.core.state.SessionItemStateManager.update(SessionItemStateManager.java:306)
> at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1244)
> ... 21 more
> Caused by: org.apache.jackrabbit.core.data.DataStoreException: Can not read
> identifier a2ada2d96d0b05214288efa03be9005a5bb98c9b: Memoria insufic
[jira] Commented: (JCR-1154) Database Data Store
[ https://issues.apache.org/jira/browse/JCR-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12552534 ] Esteban Franqueiro commented on JCR-1154: - Thomas, with the test I posted in JCR-1250 I see that there's still a copy from the DB to the local FS on the save() call (which I believe is unnecessary). Also, there are many calls to touch() inside the data store, and at least one call to getRecord(). > Database Data Store > --- > > Key: JCR-1154 > URL: https://issues.apache.org/jira/browse/JCR-1154 > Project: Jackrabbit > Issue Type: New Feature > Components: jackrabbit-core >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Blocker > Fix For: 1.4 > > Attachments: jr-1.3.1-bea.zip > > > We want to have a database backed data store implementation. > An implementation using files is already available as part of JCR-926. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1250) When adding a large (100MB) binary to the DbDataStore, it fails with an insufficient memory exception
[
https://issues.apache.org/jira/browse/JCR-1250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12552531
]
Esteban Franqueiro commented on JCR-1250:
-
Hi.
I upgraded to version 1.2 of the driver and added responseBuffering=adaptive to
my URL, but now I get the following error:
java.lang.OutOfMemoryError: Java heap space
at com.microsoft.sqlserver.jdbc.TDSPacket.(Unknown Source)
at com.microsoft.sqlserver.jdbc.TDSReader.readPacket(Unknown Source)
at com.microsoft.sqlserver.jdbc.TDSReader.readPacket(Unknown Source)
at com.microsoft.sqlserver.jdbc.TDSReader.readResponse(Unknown Source)
at com.microsoft.sqlserver.jdbc.TDSCommand.detach(Unknown Source)
at
com.microsoft.sqlserver.jdbc.SQLServerConnection.executeCommand(Unknown Source)
at
com.microsoft.sqlserver.jdbc.SQLServerStatement.executeCommand(Unknown Source)
at
com.microsoft.sqlserver.jdbc.SQLServerStatement.executeStatement(Unknown Source)
at
com.microsoft.sqlserver.jdbc.SQLServerPreparedStatement.execute(Unknown Source)
at
org.apache.jackrabbit.core.persistence.bundle.util.ConnectionRecoveryManager.executeStmtInternal(ConnectionRecoveryManager.java:362)
at
org.apache.jackrabbit.core.persistence.bundle.util.ConnectionRecoveryManager.executeStmtInternal(ConnectionRecoveryManager.java:292)
at
org.apache.jackrabbit.core.persistence.bundle.util.ConnectionRecoveryManager.executeStmt(ConnectionRecoveryManager.java:257)
at
org.apache.jackrabbit.core.persistence.bundle.util.ConnectionRecoveryManager.executeStmt(ConnectionRecoveryManager.java:237)
at
org.apache.jackrabbit.core.data.db.DbDataStore.getRecord(DbDataStore.java:457)
at
org.apache.jackrabbit.core.value.BLOBInDataStore.getDataRecord(BLOBInDataStore.java:129)
at
org.apache.jackrabbit.core.value.BLOBInDataStore.getLength(BLOBInDataStore.java:85)
at
org.apache.jackrabbit.core.persistence.util.Serializer.serialize(Serializer.java:201)
at
org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.store(DatabasePersistenceManager.java:476)
at
org.apache.jackrabbit.core.persistence.AbstractPersistenceManager.store(AbstractPersistenceManager.java:75)
at
org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.store(DatabasePersistenceManager.java:282)
at
org.apache.jackrabbit.core.state.SharedItemStateManager$Update.end(SharedItemStateManager.java:695)
at
org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:864)
at
org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:324)
at
org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:313)
at
org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:300)
at
org.apache.jackrabbit.core.state.SessionItemStateManager.update(SessionItemStateManager.java:306)
at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1244)
at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:897)
at
org.apache.jackrabbit.core.data.BigBinaryTest.testBigBinary(BigBinaryTest.java:17)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
Note that I'm using a database server, not my local machine.
Adding -Xms200m -Xmx200m seems to solve this problem.
> When adding a large (100MB) binary to the DbDataStore, it fails with an
> insufficient memory exception
> -
>
> Key: JCR-1250
> URL: https://issues.apache.org/jira/browse/JCR-1250
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-core
> Environment: Windows XP x64 client, SQL Server 2005
>Reporter: Esteban Franqueiro
>Assignee: Thomas Mueller
> Fix For: 1.4
>
> Attachments: BigBinaryTest.java
>
>
> Attached is a small test case. It fails during save(). I think this is
> related to what I mentioned in
> http://mail-archives.apache.org/mod_mbox/jackrabbit-dev/200711.mbox/[EMAIL
> PROTECTED]
> The full stacktrace is the following:
> javax.jcr.RepositoryException: /: unable to update item.: failed to write
> property state: cafebabe-cafe-babe-cafe-babecafebabe/{}bin: failed to write
> property state: cafebabe-cafe-babe-cafe-babecafebabe/{}bin
> at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1252)
> at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:858)
> at
> org.apache.jackrabbit.
[jira] Commented: (JCR-1154) Database Data Store
[ https://issues.apache.org/jira/browse/JCR-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551547 ] Esteban Franqueiro commented on JCR-1154: - Really interesting. Have you thought about the use case of the GC running in a background thread? How would you go about it? Could you post your code, as a patch maybe, to take a look a it? As you know this feature is very important for us. > Database Data Store > --- > > Key: JCR-1154 > URL: https://issues.apache.org/jira/browse/JCR-1154 > Project: Jackrabbit > Issue Type: New Feature > Components: jackrabbit-core >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Blocker > Fix For: 1.4 > > Attachments: jr-1.3.1-bea.zip > > > We want to have a database backed data store implementation. > An implementation using files is already available as part of JCR-926. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1154) Database Data Store
[ https://issues.apache.org/jira/browse/JCR-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551541 ] Esteban Franqueiro commented on JCR-1154: - Stefan, > the said method is not public since it returns *all* workspace names, > regardless of user rights. please note that > the a session must only see/know about workspaces it is actually allowed to > access. I'm working on a garbage collector for the data store. The GC doesn't care about user rights, or, putting it another way, it must be able to access all workspaces. Ideally I'd like to use a SystemSession, but you can't get one outside RepositoryImpl or o.a.j.c package (i.e., getSystemSession(String) is package private, WorkspaceInfo is protected). I understand that these APIs shouldn't be public, but they're useful from within the core. In my case, for the GC. I'm very interested in using another way to walk every workspace, but this other way should guarantee that the repository won't shutdown during a walk operation. I'll check the solution Thomas said he'll be proposing, but in the mean time that is what I'm using. Still, I don't see why this APIs aren't public. Regards > Database Data Store > --- > > Key: JCR-1154 > URL: https://issues.apache.org/jira/browse/JCR-1154 > Project: Jackrabbit > Issue Type: New Feature > Components: jackrabbit-core >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Blocker > Fix For: 1.4 > > Attachments: jr-1.3.1-bea.zip > > > We want to have a database backed data store implementation. > An implementation using files is already available as part of JCR-926. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1154) Database Data Store
[ https://issues.apache.org/jira/browse/JCR-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551512 ] Esteban Franqueiro commented on JCR-1154: - > Do you still need this? Yes. > FileDataRecord is now protected, but why do you want to extend it? I don't > think it's a good idea to re-use the class for something that it's not meant > for (it would break encapsulation). Like I said in my last message, I don't want to extend it, I want to use it from another package, so I need both the class and constructor to be public. Regards > Database Data Store > --- > > Key: JCR-1154 > URL: https://issues.apache.org/jira/browse/JCR-1154 > Project: Jackrabbit > Issue Type: New Feature > Components: jackrabbit-core >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Blocker > Fix For: 1.4 > > Attachments: jr-1.3.1-bea.zip > > > We want to have a database backed data store implementation. > An implementation using files is already available as part of JCR-926. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1154) Database Data Store
[ https://issues.apache.org/jira/browse/JCR-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_1255 ] Esteban Franqueiro commented on JCR-1154: - Hi Thomas. I noticed that you made the FileDataRecord public, but it's only constructor protected. This way you can't have a class that returns a file data record, because it can't construct one. Maybe I didn't express correctly. I want to use FileDataRecord from another package, so I need both the class and its constructor(s) to be public . For the time being I'm not extending it, but who knows :) I would also like to ask for a getLastModified() method in the DataRecord interface. Regards > Database Data Store > --- > > Key: JCR-1154 > URL: https://issues.apache.org/jira/browse/JCR-1154 > Project: Jackrabbit > Issue Type: New Feature > Components: jackrabbit-core >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Blocker > Fix For: 1.4 > > Attachments: jr-1.3.1-bea.zip > > > We want to have a database backed data store implementation. > An implementation using files is already available as part of JCR-926. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1154) Database Data Store
[ https://issues.apache.org/jira/browse/JCR-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12550996 ] Esteban Franqueiro commented on JCR-1154: - I see you have updated the impl. I'm checkin it out right now. I have a few comments: * you have to update the javadoc in DbDataStore (it has a wrong package and class name, an also the className attribute should be "class" * you left the @author tag in Pool and TempFileInputStream classes * shouldn't be better to use a larger buffer inTempFileInputStream.writeToFileAndClose()? like 64K perhaps? * what happens if two clients request the same binary at the same time? I guess the temp file doesn't overwrite the other one, so the file is copied twice, right? BTW, thanks for commiting the changes I asked for, but I still think that making RepositoryImpl.getWorkspaceNames() public will be useful (I'm using it for the GC). Regards > Database Data Store > --- > > Key: JCR-1154 > URL: https://issues.apache.org/jira/browse/JCR-1154 > Project: Jackrabbit > Issue Type: New Feature > Components: jackrabbit-core >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Blocker > Fix For: 1.4 > > Attachments: jr-1.3.1-bea.zip > > > We want to have a database backed data store implementation. > An implementation using files is already available as part of JCR-926. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-314) Fine grained locking in SharedItemStateManager
[ https://issues.apache.org/jira/browse/JCR-314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Esteban Franqueiro updated JCR-314: --- Attachment: fine-grained-locking-1.4.patch This patch adds a lockingStrategy attribute to the Workspace and Versioning element tags. It's possible values are default, fine, and fine+ (this one was a POC we did here). > Fine grained locking in SharedItemStateManager > -- > > Key: JCR-314 > URL: https://issues.apache.org/jira/browse/JCR-314 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-core >Affects Versions: 0.9, 1.0, 1.0.1, 1.1, 1.1.1, 1.2.1, 1.2.2, 1.2.3 >Reporter: Marcel Reutegger > Attachments: fine-grained-locking-1.4.patch, > FineGrainedISMLocking-v2.patch, FineGrainedISMLocking.patch, > ISMLocking.patch, writes-per-second.jpg > > > The SharedItemStateManager (SISM) currently uses a simple read-write lock to > ensure data consistency. Store operations to the PersistenceManager (PM) are > effectively serialized. > We should think about more sophisticated locking to allow concurrent writes > on the PM. > One possible approach: > If a transaction is currently storing data in a PM a second transaction may > check if the set of changes does not intersect with the first transaction. If > that is the case it can safely store its data in the PM. > This fine grained locking must also be respected when reading from the SISM. > A read request for an item that is currently being stored must be blocked > until the store is finished. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (JCR-1154) Database Data Store
[ https://issues.apache.org/jira/browse/JCR-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12550108 ] efranqueiro edited comment on JCR-1154 at 12/10/07 7:45 AM: --- Also, I think FileDataRecord class should be public, and the DataRecord interface should have a getLastModified() method. These are for extensibility. Since it's not public, it can't be extended from another package. And the method is the easyest way to get the last modified time of a DB record in my case. was (Author: efranqueiro): Also, I think DataRecord class should be public, and have a getLastModified() method. These are for extensibility. Since it's not public, it can't be extend from another package. And the method is the easyest way to get the last modified time of a DB record in my case. > Database Data Store > --- > > Key: JCR-1154 > URL: https://issues.apache.org/jira/browse/JCR-1154 > Project: Jackrabbit > Issue Type: New Feature > Components: jackrabbit-core >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Blocker > Fix For: 1.4 > > Attachments: jr-1.3.1-bea.zip > > > We want to have a database backed data store implementation. > An implementation using files is already available as part of JCR-926. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1154) Database Data Store
[ https://issues.apache.org/jira/browse/JCR-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12550108 ] Esteban Franqueiro commented on JCR-1154: - Also, I think DataRecord class should be public, and have a getLastModified() method. These are for extensibility. Since it's not public, it can't be extend from another package. And the method is the easyest way to get the last modified time of a DB record in my case. > Database Data Store > --- > > Key: JCR-1154 > URL: https://issues.apache.org/jira/browse/JCR-1154 > Project: Jackrabbit > Issue Type: New Feature > Components: jackrabbit-core >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Blocker > Fix For: 1.4 > > Attachments: jr-1.3.1-bea.zip > > > We want to have a database backed data store implementation. > An implementation using files is already available as part of JCR-926. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1154) Database Data Store
[
https://issues.apache.org/jira/browse/JCR-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12550099
]
Esteban Franqueiro commented on JCR-1154:
-
Why have to write
catch (SomeException e) {
throw new DataStoreException(e.getMessage(), e);
}
when
catch (SomeException e) {
throw new DataStoreException(e);
}
does the same?
> Database Data Store
> ---
>
> Key: JCR-1154
> URL: https://issues.apache.org/jira/browse/JCR-1154
> Project: Jackrabbit
> Issue Type: New Feature
> Components: jackrabbit-core
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
>Priority: Blocker
> Fix For: 1.4
>
> Attachments: jr-1.3.1-bea.zip
>
>
> We want to have a database backed data store implementation.
> An implementation using files is already available as part of JCR-926.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1154) Database Data Store
[ https://issues.apache.org/jira/browse/JCR-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12550093 ] Esteban Franqueiro commented on JCR-1154: - Shouldn't the DataStoreException (as well as every exception, actually) have the DataStoreException(Exception) constructor? > Database Data Store > --- > > Key: JCR-1154 > URL: https://issues.apache.org/jira/browse/JCR-1154 > Project: Jackrabbit > Issue Type: New Feature > Components: jackrabbit-core >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Blocker > Fix For: 1.4 > > Attachments: jr-1.3.1-bea.zip > > > We want to have a database backed data store implementation. > An implementation using files is already available as part of JCR-926. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1250) When adding a large (100MB) binary to the DbDataStore, it fails with an insufficient memory exception
[
https://issues.apache.org/jira/browse/JCR-1250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Esteban Franqueiro updated JCR-1250:
Attachment: BigBinaryTest.java
> When adding a large (100MB) binary to the DbDataStore, it fails with an
> insufficient memory exception
> -
>
> Key: JCR-1250
> URL: https://issues.apache.org/jira/browse/JCR-1250
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-core
>Affects Versions: 1.4
> Environment: Windows XP x64 client, SQL Server 2005
>Reporter: Esteban Franqueiro
> Attachments: BigBinaryTest.java
>
>
> Attached is a small test case. It fails during save(). I think this is
> related to what I mentioned in
> http://mail-archives.apache.org/mod_mbox/jackrabbit-dev/200711.mbox/[EMAIL
> PROTECTED]
> The full stacktrace is the following:
> javax.jcr.RepositoryException: /: unable to update item.: failed to write
> property state: cafebabe-cafe-babe-cafe-babecafebabe/{}bin: failed to write
> property state: cafebabe-cafe-babe-cafe-babecafebabe/{}bin
> at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1252)
> at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:858)
> at
> org.apache.jackrabbit.core.data.BigBinaryTest.testBigBinary(BigBinaryTest.java:16)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at junit.framework.TestCase.runTest(TestCase.java:154)
> at junit.framework.TestCase.runBare(TestCase.java:127)
> at junit.framework.TestResult$1.protect(TestResult.java:106)
> at junit.framework.TestResult.runProtected(TestResult.java:124)
> at junit.framework.TestResult.run(TestResult.java:109)
> at junit.framework.TestCase.run(TestCase.java:118)
> at
> org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:404)
> at junit.framework.TestSuite.runTest(TestSuite.java:208)
> at junit.framework.TestSuite.run(TestSuite.java:203)
> at
> org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128)
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
> Caused by: org.apache.jackrabbit.core.state.ItemStateException: failed to
> write property state: cafebabe-cafe-babe-cafe-babecafebabe/{}bin
> at
> org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.store(DatabasePersistenceManager.java:487)
> at
> org.apache.jackrabbit.core.persistence.AbstractPersistenceManager.store(AbstractPersistenceManager.java:75)
> at
> org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.store(DatabasePersistenceManager.java:282)
> at
> org.apache.jackrabbit.core.state.SharedItemStateManager$Update.end(SharedItemStateManager.java:687)
> at
> org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:856)
> at
> org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:324)
> at
> org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:313)
> at
> org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:300)
> at
> org.apache.jackrabbit.core.state.SessionItemStateManager.update(SessionItemStateManager.java:306)
> at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1244)
> ... 21 more
> Caused by: org.apache.jackrabbit.core.data.DataStoreException: Can not read
> identifier a2ada2d96d0b05214288efa03be9005a5bb98c9b: Memoria insuficiente.
> Utilice cursores del servidor para result sets grandes:Java heap space.
> Tamaño de result set:104.857.723. Tamaño memoria total JVM:66.650.112.:
> Memoria insuficiente. Utilice cursores del servidor para result sets
> grandes:Java heap space. Tamaño de result set:104.857.723. Tamaño memoria
> total JVM:66.650.112.
> at
> org.apache.jackrabbit.core.data.db.DbDataStore.convert(DbDataStore.java:438)
> at
> org.apache.jackrabbit.core.data.db.DbDataStore.getInputStream(DbDataStore.jav
[jira] Created: (JCR-1250) When adding a large (100MB) binary to the DbDataStore, it fails with an insufficient memory exception
When adding a large (100MB) binary to the DbDataStore, it fails with an
insufficient memory exception
-
Key: JCR-1250
URL: https://issues.apache.org/jira/browse/JCR-1250
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-core
Affects Versions: 1.4
Environment: Windows XP x64 client, SQL Server 2005
Reporter: Esteban Franqueiro
Attached is a small test case. It fails during save(). I think this is related
to what I mentioned in
http://mail-archives.apache.org/mod_mbox/jackrabbit-dev/200711.mbox/[EMAIL
PROTECTED]
The full stacktrace is the following:
javax.jcr.RepositoryException: /: unable to update item.: failed to write
property state: cafebabe-cafe-babe-cafe-babecafebabe/{}bin: failed to write
property state: cafebabe-cafe-babe-cafe-babecafebabe/{}bin
at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1252)
at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:858)
at
org.apache.jackrabbit.core.data.BigBinaryTest.testBigBinary(BigBinaryTest.java:16)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at
org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:404)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at
org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:128)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
Caused by: org.apache.jackrabbit.core.state.ItemStateException: failed to write
property state: cafebabe-cafe-babe-cafe-babecafebabe/{}bin
at
org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.store(DatabasePersistenceManager.java:487)
at
org.apache.jackrabbit.core.persistence.AbstractPersistenceManager.store(AbstractPersistenceManager.java:75)
at
org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManager.store(DatabasePersistenceManager.java:282)
at
org.apache.jackrabbit.core.state.SharedItemStateManager$Update.end(SharedItemStateManager.java:687)
at
org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:856)
at
org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:324)
at
org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:313)
at
org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:300)
at
org.apache.jackrabbit.core.state.SessionItemStateManager.update(SessionItemStateManager.java:306)
at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1244)
... 21 more
Caused by: org.apache.jackrabbit.core.data.DataStoreException: Can not read
identifier a2ada2d96d0b05214288efa03be9005a5bb98c9b: Memoria insuficiente.
Utilice cursores del servidor para result sets grandes:Java heap space. Tamaño
de result set:104.857.723. Tamaño memoria total JVM:66.650.112.: Memoria
insuficiente. Utilice cursores del servidor para result sets grandes:Java heap
space. Tamaño de result set:104.857.723. Tamaño memoria total JVM:66.650.112.
at
org.apache.jackrabbit.core.data.db.DbDataStore.convert(DbDataStore.java:438)
at
org.apache.jackrabbit.core.data.db.DbDataStore.getInputStream(DbDataStore.java:481)
at
org.apache.jackrabbit.core.data.db.DbDataRecord.getStream(DbDataRecord.java:61)
at
org.apache.jackrabbit.core.value.BLOBInDataStore.getStream(BLOBInDataStore.java:93)
at
org.apache.jackrabbit.core.persistence.util.Serializer.serialize(Serializer.java:198)
at
org.apache.jackrabbit.core.persistence.db.DatabasePersistenceManag
[jira] Created: (JCR-1246) In DatabasePersistenceManager.store(), if the exception is null or its cause is not an SQLException, then the PM keeps looping forever
In DatabasePersistenceManager.store(), if the exception is null or its cause is
not an SQLException, then the PM keeps looping forever
--
Key: JCR-1246
URL: https://issues.apache.org/jira/browse/JCR-1246
Project: Jackrabbit
Issue Type: Bug
Components: jackrabbit-core
Environment: Windows XP x64
Reporter: Esteban Franqueiro
In the line
if (ise != null && ise.getCause() instanceof SQLException && --trials > 0) {
if one of the first two checks fails, the shortcircuit doesn't decrement trials.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-73) Improve Javadoc documentation
[ https://issues.apache.org/jira/browse/JCR-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545109 ] Esteban Franqueiro commented on JCR-73: --- The sentence "The commit may haven implicitly in case the Content Repository is not running in an XA environment" should be correctly re-written in the item Transactional ISM of http://jackrabbit.apache.org/doc/arch/operate/index.html. > Improve Javadoc documentation > - > > Key: JCR-73 > URL: https://issues.apache.org/jira/browse/JCR-73 > Project: Jackrabbit > Issue Type: Improvement > Components: docs >Reporter: Jukka Zitting >Priority: Minor > Fix For: none > > > This is an ongoing meta-issue for improving the state of documentation in > Jackrabbit. After a long history of following the maturing JSR 170 > specification, the Jackrabbit codebase contains many parts that would benefit > from better documentation. This issue is a call to arms for a community > effort to improve the Javadoc documentation of Jackrabbit. > By this issue, you have an open mandate to improve the Javadoc documentation > of any relatively stable part of Jackrabbit (no major changes during the last > few weeks). You are free to contribute even partial and cursory > documentation. Just follow the instructions below! > Instructions for non-committers: > If you want to help in improving the Javadoc documentation of Jackrabbit, > please send your improvements as attachments to this issue. The best way to > do this is to first check out the Jackrabbit source tree using anonymous > Subversion, then make the Javadoc improvements you like, and finally use "svn > diff" to generate a diff file that contains all your changes. You can then > attach the diff file to this issue by following the "Attach file" link in the > sidebar. Please remember to grant us the rights to include your changes (use > the ASF grant option on the upload page). You may also want to write a short > summary comment about the Javadoc improvements you made. > If you want to make changes also to the Jackrabbit code, then please send > your changes to another issue. This issue is reserved only for Javadoc > improvements. > Instructions for committers: > Please label your Javadoc commit messages with the Jira key (JCR-73) of this > issue to mark the changes as document-only. This way other committers won't > need to check your changes for bugs or other unexpected side-effects. Please > follow the same guidelines also when committing Javadoc changes sent by > non-committers. > This issue should remain as an unassigned and open issue at least for now. If > this approach turns out to complicate Jira reports, then we can switch to > another mechanism for handling Javadoc improvements. In that case this issue > should be closed with a comment that explains the changes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-73) Improve Javadoc documentation
[ https://issues.apache.org/jira/browse/JCR-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545108 ] Esteban Franqueiro commented on JCR-73: --- http://jackrabbit.apache.org/doc/arch/operate/startup.html says the default configuration file is called config.xml. Shouldn't be repository.xml? > Improve Javadoc documentation > - > > Key: JCR-73 > URL: https://issues.apache.org/jira/browse/JCR-73 > Project: Jackrabbit > Issue Type: Improvement > Components: docs >Reporter: Jukka Zitting >Priority: Minor > Fix For: none > > > This is an ongoing meta-issue for improving the state of documentation in > Jackrabbit. After a long history of following the maturing JSR 170 > specification, the Jackrabbit codebase contains many parts that would benefit > from better documentation. This issue is a call to arms for a community > effort to improve the Javadoc documentation of Jackrabbit. > By this issue, you have an open mandate to improve the Javadoc documentation > of any relatively stable part of Jackrabbit (no major changes during the last > few weeks). You are free to contribute even partial and cursory > documentation. Just follow the instructions below! > Instructions for non-committers: > If you want to help in improving the Javadoc documentation of Jackrabbit, > please send your improvements as attachments to this issue. The best way to > do this is to first check out the Jackrabbit source tree using anonymous > Subversion, then make the Javadoc improvements you like, and finally use "svn > diff" to generate a diff file that contains all your changes. You can then > attach the diff file to this issue by following the "Attach file" link in the > sidebar. Please remember to grant us the rights to include your changes (use > the ASF grant option on the upload page). You may also want to write a short > summary comment about the Javadoc improvements you made. > If you want to make changes also to the Jackrabbit code, then please send > your changes to another issue. This issue is reserved only for Javadoc > improvements. > Instructions for committers: > Please label your Javadoc commit messages with the Jira key (JCR-73) of this > issue to mark the changes as document-only. This way other committers won't > need to check your changes for bugs or other unexpected side-effects. Please > follow the same guidelines also when committing Javadoc changes sent by > non-committers. > This issue should remain as an unassigned and open issue at least for now. If > this approach turns out to complicate Jira reports, then we can switch to > another mechanism for handling Javadoc improvements. In that case this issue > should be closed with a comment that explains the changes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1232) Merge UUID to NodeId
[ https://issues.apache.org/jira/browse/JCR-1232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545070 ] Esteban Franqueiro commented on JCR-1232: - To cope with the existing code, shouldn't be public interface ItemId extends Serializable? > Merge UUID to NodeId > > > Key: JCR-1232 > URL: https://issues.apache.org/jira/browse/JCR-1232 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-core >Reporter: Jukka Zitting >Priority: Minor > Attachments: nodeId.patch, nodeid.patch > > > The current NodeId class is mostly just a wrapper around UUID, which causes > two objects to be instantiated for each node identifier that the system uses. > The memory and processing overhead is quite small, but given that there are > tons of NodeId instances it would be good to eliminate that overhead. > There is also lots of code that just converts UUIDs to NodeIds and vice > versa. We could simplify such code if we just used NodeId everywhere. > Also, we might want to open up the possibility of using non-UUID node > identifiers at some point in future, so it would make a lot of sense to > remove the NodeId.getUUID method and rely directly on NodeId and it's > equals(), hashCode(), and toString() methods in many places where we > currently use UUIDs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1232) Merge UUID to NodeId
[
https://issues.apache.org/jira/browse/JCR-1232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545041
]
Esteban Franqueiro commented on JCR-1232:
-
If getUUID() is used by applications, then I would say a behavior like the
following is necessary, at least for the near future in order not to break them.
>/**
> * @deprecated
> */
>public UUID getUUID() {
>return new UUID(msb, lsb);
>}
If not, the docs should say how to replace its functionality.
> Merge UUID to NodeId
>
>
> Key: JCR-1232
> URL: https://issues.apache.org/jira/browse/JCR-1232
> Project: Jackrabbit
> Issue Type: Improvement
> Components: jackrabbit-core
>Reporter: Jukka Zitting
>Priority: Minor
> Attachments: nodeid.patch
>
>
> The current NodeId class is mostly just a wrapper around UUID, which causes
> two objects to be instantiated for each node identifier that the system uses.
> The memory and processing overhead is quite small, but given that there are
> tons of NodeId instances it would be good to eliminate that overhead.
> There is also lots of code that just converts UUIDs to NodeIds and vice
> versa. We could simplify such code if we just used NodeId everywhere.
> Also, we might want to open up the possibility of using non-UUID node
> identifiers at some point in future, so it would make a lot of sense to
> remove the NodeId.getUUID method and rely directly on NodeId and it's
> equals(), hashCode(), and toString() methods in many places where we
> currently use UUIDs.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-73) Improve Javadoc documentation
[ https://issues.apache.org/jira/browse/JCR-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544877 ] Esteban Franqueiro commented on JCR-73: --- * @return true if consistent check is enabled. (in revision 597414) should be * @return true if consistency check is enabled. > Improve Javadoc documentation > - > > Key: JCR-73 > URL: https://issues.apache.org/jira/browse/JCR-73 > Project: Jackrabbit > Issue Type: Improvement > Components: docs >Reporter: Jukka Zitting >Priority: Minor > Fix For: none > > > This is an ongoing meta-issue for improving the state of documentation in > Jackrabbit. After a long history of following the maturing JSR 170 > specification, the Jackrabbit codebase contains many parts that would benefit > from better documentation. This issue is a call to arms for a community > effort to improve the Javadoc documentation of Jackrabbit. > By this issue, you have an open mandate to improve the Javadoc documentation > of any relatively stable part of Jackrabbit (no major changes during the last > few weeks). You are free to contribute even partial and cursory > documentation. Just follow the instructions below! > Instructions for non-committers: > If you want to help in improving the Javadoc documentation of Jackrabbit, > please send your improvements as attachments to this issue. The best way to > do this is to first check out the Jackrabbit source tree using anonymous > Subversion, then make the Javadoc improvements you like, and finally use "svn > diff" to generate a diff file that contains all your changes. You can then > attach the diff file to this issue by following the "Attach file" link in the > sidebar. Please remember to grant us the rights to include your changes (use > the ASF grant option on the upload page). You may also want to write a short > summary comment about the Javadoc improvements you made. > If you want to make changes also to the Jackrabbit code, then please send > your changes to another issue. This issue is reserved only for Javadoc > improvements. > Instructions for committers: > Please label your Javadoc commit messages with the Jira key (JCR-73) of this > issue to mark the changes as document-only. This way other committers won't > need to check your changes for bugs or other unexpected side-effects. Please > follow the same guidelines also when committing Javadoc changes sent by > non-committers. > This issue should remain as an unassigned and open issue at least for now. If > this approach turns out to complicate Jira reports, then we can switch to > another mechanism for handling Javadoc improvements. In that case this issue > should be closed with a comment that explains the changes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1206) UUID generation: SecureRandom should be used by default
[ https://issues.apache.org/jira/browse/JCR-1206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542199 ] Esteban Franqueiro commented on JCR-1206: - Why not use UUID.randomUUID() directly? > UUID generation: SecureRandom should be used by default > --- > > Key: JCR-1206 > URL: https://issues.apache.org/jira/browse/JCR-1206 > Project: Jackrabbit > Issue Type: Improvement > Components: jackrabbit-core >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Fix For: 1.4 > > > Currently, the UUID generation used the regular java.util.Random > implementation to generate random UUIDs. The seed value of Random is > initialized using System.currentTimeMillis(); for Windows, the resolution is > about 15 milliseconds. That means two computer that start creating UUIDs with > Jackrabbit within the same 15 millisecond interval will generate the same > UUIDs. In a clustered environment the nodes could be started automatically at > the same time (for example after a backup). > Also, the Random class uses a 48-bit seed, which is much less than the number > of random bits in UUID (122). This is not secure. See also: > http://en.wikipedia.org/wiki/UUID > Random UUID probability of duplicates > "The probability [of duplicates] also depends on the quality of the random > number generator. A cryptographically secure pseudorandom number generator > must be used to generate the values, otherwise the probability of duplicates > may be significantly higher." > Therefore, I suggest to change VersionFourGenerator to use the SecureRandom > implementation in by default. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1154) Database Data Store
[ https://issues.apache.org/jira/browse/JCR-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539451 ] Esteban Franqueiro commented on JCR-1154: - See http://www.nabble.com/Re%3A--jira--Commented%3A-%28JCR-1154%29-Database-Data-Store-p13535861.html for response. > Database Data Store > --- > > Key: JCR-1154 > URL: https://issues.apache.org/jira/browse/JCR-1154 > Project: Jackrabbit > Issue Type: New Feature > Components: jackrabbit-core >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Blocker > Fix For: 1.4 > > Attachments: jr-1.3.1-bea.zip > > > We want to have a database backed data store implementation. > An implementation using files is already available as part of JCR-926. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1187) Asking a property twice for it's stream returns the same stream instance
[ https://issues.apache.org/jira/browse/JCR-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12537642 ] Esteban Franqueiro commented on JCR-1187: - I agree with you Stefan. This issue has been fixed in our implementation. When JCR-1154 is completed, we'll upload our changes for review... if Thomas doesn't fix the issue first ;) > Asking a property twice for it's stream returns the same stream instance > > > Key: JCR-1187 > URL: https://issues.apache.org/jira/browse/JCR-1187 > Project: Jackrabbit > Issue Type: Bug > Components: jackrabbit-core >Reporter: Esteban Franqueiro > Attachments: DataStoreTestUtils.java, TestTwoGetStreams.java > > > If you ask a property stored in the database data store (JCR-1154) for it's > associated stream twice, the stream instance returned is the same. This > behavior is not consistent with the file data store, which returns a > different stream instance each time Property.getStream() is called. > I'm attaching a test case wich demostrates the issue. > We're working on this and have a potencial fix for it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1187) Asking a property twice for it's stream returns the same stream instance
[ https://issues.apache.org/jira/browse/JCR-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Esteban Franqueiro updated JCR-1187: Attachment: (was: TestTwoGetStreams.java) > Asking a property twice for it's stream returns the same stream instance > > > Key: JCR-1187 > URL: https://issues.apache.org/jira/browse/JCR-1187 > Project: Jackrabbit > Issue Type: Bug > Components: jackrabbit-core >Reporter: Esteban Franqueiro > Attachments: DataStoreTestUtils.java, TestTwoGetStreams.java > > > If you ask a property stored in the database data store (JCR-1154) for it's > associated stream twice, the stream instance returned is the same. This > behavior is not consistent with the file data store, which returns a > different stream instance each time Property.getStream() is called. > I'm attaching a test case wich demostrates the issue. > We're working on this and have a potencial fix for it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1187) Asking a property twice for it's stream returns the same stream instance
[ https://issues.apache.org/jira/browse/JCR-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Esteban Franqueiro updated JCR-1187: Attachment: TestTwoGetStreams.java > Asking a property twice for it's stream returns the same stream instance > > > Key: JCR-1187 > URL: https://issues.apache.org/jira/browse/JCR-1187 > Project: Jackrabbit > Issue Type: Bug > Components: jackrabbit-core >Reporter: Esteban Franqueiro > Attachments: DataStoreTestUtils.java, TestTwoGetStreams.java > > > If you ask a property stored in the database data store (JCR-1154) for it's > associated stream twice, the stream instance returned is the same. This > behavior is not consistent with the file data store, which returns a > different stream instance each time Property.getStream() is called. > I'm attaching a test case wich demostrates the issue. > We're working on this and have a potencial fix for it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1187) Asking a property twice for it's stream returns the same stream instance
[ https://issues.apache.org/jira/browse/JCR-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Esteban Franqueiro updated JCR-1187: Description: If you ask a property stored in the database data store (JCR-1154) for it's associated stream twice, the stream instance returned is the same. This behavior is not consistent with the file data store, which returns a different stream instance each time Property.getStream() is called. I'm attaching a test case wich demostrates the issue. We're working on this and have a potencial fix for it. was: If you ask a property for it's associated stream twice, even if you don't read from any of the streams, the stream instance returned is the same. This behavior is not consistent with the file data store, which returns a different stream instance each time Property.getStream() is called. I'm attaching a test case wich demostrates the issue. We're working on this and have a potencial fix for it. > Asking a property twice for it's stream returns the same stream instance > > > Key: JCR-1187 > URL: https://issues.apache.org/jira/browse/JCR-1187 > Project: Jackrabbit > Issue Type: Bug > Components: jackrabbit-core >Reporter: Esteban Franqueiro > Attachments: DataStoreTestUtils.java, TestTwoGetStreams.java > > > If you ask a property stored in the database data store (JCR-1154) for it's > associated stream twice, the stream instance returned is the same. This > behavior is not consistent with the file data store, which returns a > different stream instance each time Property.getStream() is called. > I'm attaching a test case wich demostrates the issue. > We're working on this and have a potencial fix for it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1187) Asking a property twice for it's stream returns the same stream instance
[ https://issues.apache.org/jira/browse/JCR-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Esteban Franqueiro updated JCR-1187: Attachment: DataStoreTestUtils.java TestTwoGetStreams.java > Asking a property twice for it's stream returns the same stream instance > > > Key: JCR-1187 > URL: https://issues.apache.org/jira/browse/JCR-1187 > Project: Jackrabbit > Issue Type: Bug > Components: jackrabbit-core >Reporter: Esteban Franqueiro > Attachments: DataStoreTestUtils.java, TestTwoGetStreams.java > > > If you ask a property for it's associated stream twice, even if you don't > read from any of the streams, the stream instance returned is the same. This > behavior is not consistent with the file data store, which returns a > different stream instance each time Property.getStream() is called. > I'm attaching a test case wich demostrates the issue. > We're working on this and have a potencial fix for it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (JCR-1187) Asking a property twice for it's stream returns the same stream instance
Asking a property twice for it's stream returns the same stream instance Key: JCR-1187 URL: https://issues.apache.org/jira/browse/JCR-1187 Project: Jackrabbit Issue Type: Bug Components: jackrabbit-core Reporter: Esteban Franqueiro If you ask a property for it's associated stream twice, even if you don't read from any of the streams, the stream instance returned is the same. This behavior is not consistent with the file data store, which returns a different stream instance each time Property.getStream() is called. I'm attaching a test case wich demostrates the issue. We're working on this and have a potencial fix for it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1154) Database Data Store
[ https://issues.apache.org/jira/browse/JCR-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Esteban Franqueiro updated JCR-1154: Attachment: jr-1.3.1-bea.zip Changed attachment name. > Database Data Store > --- > > Key: JCR-1154 > URL: https://issues.apache.org/jira/browse/JCR-1154 > Project: Jackrabbit > Issue Type: New Feature > Components: jackrabbit-core >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Fix For: 1.4 > > Attachments: jr-1.3.1-bea.zip > > > We want to have a database backed data store implementation. > An implementation using files is already available as part of JCR-926. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1154) Database Data Store
[ https://issues.apache.org/jira/browse/JCR-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Esteban Franqueiro updated JCR-1154: Attachment: (was: jr-1.3.1-eaf.zip) > Database Data Store > --- > > Key: JCR-1154 > URL: https://issues.apache.org/jira/browse/JCR-1154 > Project: Jackrabbit > Issue Type: New Feature > Components: jackrabbit-core >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Fix For: 1.4 > > > We want to have a database backed data store implementation. > An implementation using files is already available as part of JCR-926. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (JCR-1154) Database Data Store
[ https://issues.apache.org/jira/browse/JCR-1154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Esteban Franqueiro updated JCR-1154: Attachment: jr-1.3.1-eaf.zip This is an implementation of a database-based data store. It currently uses SQL Server but this can be changed by subclassing the DatabaseDataStore class and overriding its buildSQLStatements() method as usual. As discussed, this impl uses UUIDs for the record id's, but we'll be working out a solution like the one proposed by Thomas. Also included is a garbage collector (based on the initial implementation by Thomas). The changes are mostly cosmetic, to generalize it for the file and database DS. In RepositoryImpl's constructor is the code to initialize the garbage collector, according to the configuration in the repository.xml file. In the included InternalValue we added methods useDataStore()/setDataStore() so we can avoid relaying on the system property. There are a few tests, for different cases (we couldn't cover every corner case, of course). Please note that there are a few design decisions in which we had to take into account the application we're building on top of Jackrabbit, but we tried very hard to keep these to a minimum while at the same time trying to simplify each time we have to update the version of Jackrabbit, since our application extends some of it's functionality (specifically, the database data store :-) ). I mention the ones I remember now: the boolean parameter in DatabaseDataStore.getConnection(), and the DatabaseRecord implementation. We should further discuss these issues. Finally, note that the attachment is NOT a patch since my working version has many patches applied to it. > Database Data Store > --- > > Key: JCR-1154 > URL: https://issues.apache.org/jira/browse/JCR-1154 > Project: Jackrabbit > Issue Type: New Feature > Components: jackrabbit-core >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Fix For: 1.4 > > Attachments: jr-1.3.1-eaf.zip > > > We want to have a database backed data store implementation. > An implementation using files is already available as part of JCR-926. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (JCR-1148) NullPointerException in ItemState
[ https://issues.apache.org/jira/browse/JCR-1148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12531022 ] efranqueiro edited comment on JCR-1148 at 9/28/07 7:34 AM: -- This issue is the same one Pablo mentioned in JCR-935. Are you using the fine grained locking strategy? Because in our testing this happened when using it. was (Author: efranqueiro): This issue is related to JCR-935. > NullPointerException in ItemState > - > > Key: JCR-1148 > URL: https://issues.apache.org/jira/browse/JCR-1148 > Project: Jackrabbit > Issue Type: Bug > Components: jackrabbit-core >Affects Versions: 1.3 >Reporter: Martijn Hendriks > > The following happens quite regularly when multiple threads are adding, > retrieving and removing nodes simultaneously. Looking at the code of the pull > method, this seems due to under-synchronization somewhere as overlayedState > was tested at line 153 for null. > java.lang.NullPointerException > at org.apache.jackrabbit.core.state.ItemState.pull(ItemState.java:156) > at > org.apache.jackrabbit.core.state.LocalItemStateManager.stateModified(LocalItemStateManager.java:421) > at > org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateModified(StateChangeDispatcher.java:85) > at > org.apache.jackrabbit.core.state.SharedItemStateManager.stateModified(SharedItemStateManager.java:434) > at > org.apache.jackrabbit.core.state.ItemState.notifyStateUpdated(ItemState.java:241) > at > org.apache.jackrabbit.core.state.ChangeLog.persisted(ChangeLog.java:271) > at > org.apache.jackrabbit.core.state.SharedItemStateManager$Update.end(SharedItemStateManager.java:741) > at > org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:937) > at > org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:327) > at > org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:313) > at > org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:303) > at > org.apache.jackrabbit.core.state.SessionItemStateManager.update(SessionItemStateManager.java:307) > at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1374) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-1148) NullPointerException in ItemState
[ https://issues.apache.org/jira/browse/JCR-1148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12531022 ] Esteban Franqueiro commented on JCR-1148: - This issue is related to JCR-935. > NullPointerException in ItemState > - > > Key: JCR-1148 > URL: https://issues.apache.org/jira/browse/JCR-1148 > Project: Jackrabbit > Issue Type: Bug > Components: jackrabbit-core >Affects Versions: 1.3 >Reporter: Martijn Hendriks > > The following happens quite regularly when multiple threads are adding, > retrieving and removing nodes simultaneously. Looking at the code of the pull > method, this seems due to under-synchronization somewhere as overlayedState > was tested at line 153 for null. > java.lang.NullPointerException > at org.apache.jackrabbit.core.state.ItemState.pull(ItemState.java:156) > at > org.apache.jackrabbit.core.state.LocalItemStateManager.stateModified(LocalItemStateManager.java:421) > at > org.apache.jackrabbit.core.state.StateChangeDispatcher.notifyStateModified(StateChangeDispatcher.java:85) > at > org.apache.jackrabbit.core.state.SharedItemStateManager.stateModified(SharedItemStateManager.java:434) > at > org.apache.jackrabbit.core.state.ItemState.notifyStateUpdated(ItemState.java:241) > at > org.apache.jackrabbit.core.state.ChangeLog.persisted(ChangeLog.java:271) > at > org.apache.jackrabbit.core.state.SharedItemStateManager$Update.end(SharedItemStateManager.java:741) > at > org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:937) > at > org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:327) > at > org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:313) > at > org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:303) > at > org.apache.jackrabbit.core.state.SessionItemStateManager.update(SessionItemStateManager.java:307) > at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1374) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-935) ConcurrentModificationException during logout (cont'd)
[ https://issues.apache.org/jira/browse/JCR-935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528872 ] Esteban Franqueiro commented on JCR-935: Hi Stefan. Although I fully agree with you in that our workaround can cause deadlocks, this didn't happen in our testing. All tests (jcr-tests, core tests, MT tests and application level tests) pass. Regarding the status of this issue, maybe for version 2 we can do something better, but in the meantime we think these changes are a step forward. We will work more on this issue as our knowledge of the core grows and allows us to dig deeper. But for the time being we report our findings :) Regards, Esteban > ConcurrentModificationException during logout (cont'd) > -- > > Key: JCR-935 > URL: https://issues.apache.org/jira/browse/JCR-935 > Project: Jackrabbit > Issue Type: Bug > Components: core >Affects Versions: 1.3 >Reporter: Pablo Rios > > I "seldom" get a CME running ConcurrentReadWriteTest.testReadWrite test. > Following are different stack traces of two runs: > > Exception in thread "Thread-9" java.util.ConcurrentModificationException > at > org.apache.commons.collections.map.AbstractReferenceMap$ReferenceEntrySetIterator.checkMod(AbstractReferenceMap.java:761) > at > org.apache.commons.collections.map.AbstractReferenceMap$ReferenceEntrySetIterator.hasNext(AbstractReferenceMap.java:735) > at > org.apache.commons.collections.map.AbstractReferenceMap$ReferenceValues.toArray(AbstractReferenceMap.java:543) > at java.util.Collections$UnmodifiableCollection.toArray(Unknown Source) > at java.util.Collections$UnmodifiableCollection.toArray(Unknown Source) > at > org.apache.jackrabbit.core.state.LocalItemStateManager.dispose(LocalItemStateManager.java:341) > at > org.apache.jackrabbit.core.state.SessionItemStateManager.dispose(SessionItemStateManager.java:316) > at org.apache.jackrabbit.core.SessionImpl.logout(SessionImpl.java:1269) > at org.apache.jackrabbit.core.XASessionImpl.logout(XASessionImpl.java:379) > at > org.apache.jackrabbit.core.AbstractConcurrencyTest$Executor.run(AbstractConcurrencyTest.java:114) > at java.lang.Thread.run(Unknown Source) > Exception in thread "Thread-9" java.util.ConcurrentModificationException > at > org.apache.commons.collections.map.AbstractReferenceMap$ReferenceEntrySetIterator.checkMod(AbstractReferenceMap.java:761) > at > org.apache.commons.collections.map.AbstractReferenceMap$ReferenceEntrySetIterator.nextEntry(AbstractReferenceMap.java:770) > at > org.apache.commons.collections.map.AbstractReferenceMap$ReferenceValuesIterator.next(AbstractReferenceMap.java:829) > at > org.apache.commons.collections.map.AbstractReferenceMap$ReferenceValues.toArray(AbstractReferenceMap.java:544) > at java.util.Collections$UnmodifiableCollection.toArray(Unknown Source) > at java.util.Collections$UnmodifiableCollection.toArray(Unknown Source) > at > org.apache.jackrabbit.core.state.LocalItemStateManager.dispose(LocalItemStateManager.java:341) > at > org.apache.jackrabbit.core.state.SessionItemStateManager.dispose(SessionItemStateManager.java:316) > at org.apache.jackrabbit.core.SessionImpl.logout(SessionImpl.java:1269) > at > org.apache.jackrabbit.core.XASessionImpl.logout(XASessionImpl.java:379) > at > org.apache.jackrabbit.core.AbstractConcurrencyTest$Executor.run(AbstractConcurrencyTest.java:114) > at java.lang.Thread.run(Unknown Source) > My working copy is revision 538918 with both JCR-314 patches applied, using > FineGrainedISMLocking strategy. > I run this test manually from within Eclipse 3.2.1 / JRE 1.5.0_10-b03. > The workstation were I run this test has an Intel Dual-Core Xeon 5130 2 GHz. > To able to compare this CPU with another, with the default params of this > test (NUM_NODES = 5, NUM_THREADS = 5, RUN_NUM_SECONDS = 20), the number of > operations are ~ #writes performed: 300-400, #reads performed: 470 - > 490. > Regards, > Pablo -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (JCR-935) ConcurrentModificationException during logout (cont'd)
[ https://issues.apache.org/jira/browse/JCR-935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524579 ] efranqueiro edited comment on JCR-935 at 9/17/07 11:56 AM: -- Regarding the NPE that Pablo mentioned, it looks like a race condition, because the code first checks for != null, and then you get an NPE. The problem seems to disappear by synchronizing the pull(), connect(), reconnect(), disconnect(), isConnected(), isStale() and hasOverlayedState() methods of the class ItemState. According to the results of the test Pablo mentioned, it seems that sync'ing these methods doesn't add too much serialization. Still, we're wondering what do you all think about this, because although it works in the test, we don't know if there's a better (or may be correct) way of solving this issue. Regards, Esteban was (Author: efranqueiro): Regarding the NPE that Pablo mentioned, it looks like a race condition, because the code first checks for != null, and then you get an NPE. The problem seems to disappear by synchronizing the pull(), connect(), reconnect(), disconnect(), isConnected(), isStale() and hasOverlayedState() methods. According to the results of the test Pablo mentioned, it seems that sync'ing these methods doesn't add too much serialization. Still. we're wondering what do you all think about this, because although it works in the test, we don't know if there's a better (or may be correct) way of solving this issue. Regards, Esteban > ConcurrentModificationException during logout (cont'd) > -- > > Key: JCR-935 > URL: https://issues.apache.org/jira/browse/JCR-935 > Project: Jackrabbit > Issue Type: Bug > Components: core >Affects Versions: 1.3 >Reporter: Pablo Rios > > I "seldom" get a CME running ConcurrentReadWriteTest.testReadWrite test. > Following are different stack traces of two runs: > > Exception in thread "Thread-9" java.util.ConcurrentModificationException > at > org.apache.commons.collections.map.AbstractReferenceMap$ReferenceEntrySetIterator.checkMod(AbstractReferenceMap.java:761) > at > org.apache.commons.collections.map.AbstractReferenceMap$ReferenceEntrySetIterator.hasNext(AbstractReferenceMap.java:735) > at > org.apache.commons.collections.map.AbstractReferenceMap$ReferenceValues.toArray(AbstractReferenceMap.java:543) > at java.util.Collections$UnmodifiableCollection.toArray(Unknown Source) > at java.util.Collections$UnmodifiableCollection.toArray(Unknown Source) > at > org.apache.jackrabbit.core.state.LocalItemStateManager.dispose(LocalItemStateManager.java:341) > at > org.apache.jackrabbit.core.state.SessionItemStateManager.dispose(SessionItemStateManager.java:316) > at org.apache.jackrabbit.core.SessionImpl.logout(SessionImpl.java:1269) > at org.apache.jackrabbit.core.XASessionImpl.logout(XASessionImpl.java:379) > at > org.apache.jackrabbit.core.AbstractConcurrencyTest$Executor.run(AbstractConcurrencyTest.java:114) > at java.lang.Thread.run(Unknown Source) > Exception in thread "Thread-9" java.util.ConcurrentModificationException > at > org.apache.commons.collections.map.AbstractReferenceMap$ReferenceEntrySetIterator.checkMod(AbstractReferenceMap.java:761) > at > org.apache.commons.collections.map.AbstractReferenceMap$ReferenceEntrySetIterator.nextEntry(AbstractReferenceMap.java:770) > at > org.apache.commons.collections.map.AbstractReferenceMap$ReferenceValuesIterator.next(AbstractReferenceMap.java:829) > at > org.apache.commons.collections.map.AbstractReferenceMap$ReferenceValues.toArray(AbstractReferenceMap.java:544) > at java.util.Collections$UnmodifiableCollection.toArray(Unknown Source) > at java.util.Collections$UnmodifiableCollection.toArray(Unknown Source) > at > org.apache.jackrabbit.core.state.LocalItemStateManager.dispose(LocalItemStateManager.java:341) > at > org.apache.jackrabbit.core.state.SessionItemStateManager.dispose(SessionItemStateManager.java:316) > at org.apache.jackrabbit.core.SessionImpl.logout(SessionImpl.java:1269) > at > org.apache.jackrabbit.core.XASessionImpl.logout(XASessionImpl.java:379) > at > org.apache.jackrabbit.core.AbstractConcurrencyTest$Executor.run(AbstractConcurrencyTest.java:114) > at java.lang.Thread.run(Unknown Source) > My working copy is revision 538918 with both JCR-314 patches applied, using > FineGrainedISMLocking strategy. > I run this test manually from within Eclipse 3.2.1 / JRE 1.5.0_10-b03. > The workstation were I run this test has an Intel Dual-Core Xeon 5130 2 GHz. > To able to compare this CPU with another, with the default params of this > test (NUM_NODES = 5, NUM_THREADS = 5, RUN_NUM_SECONDS = 20), the number of > operations are ~ #writes performed: 300-400, #reads perfor
[jira] Commented: (JCR-935) ConcurrentModificationException during logout (cont'd)
[ https://issues.apache.org/jira/browse/JCR-935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528113 ] Esteban Franqueiro commented on JCR-935: We also sync'ed push() and getOverlayedState() in ItemState class. Regards, > ConcurrentModificationException during logout (cont'd) > -- > > Key: JCR-935 > URL: https://issues.apache.org/jira/browse/JCR-935 > Project: Jackrabbit > Issue Type: Bug > Components: core >Affects Versions: 1.3 >Reporter: Pablo Rios > > I "seldom" get a CME running ConcurrentReadWriteTest.testReadWrite test. > Following are different stack traces of two runs: > > Exception in thread "Thread-9" java.util.ConcurrentModificationException > at > org.apache.commons.collections.map.AbstractReferenceMap$ReferenceEntrySetIterator.checkMod(AbstractReferenceMap.java:761) > at > org.apache.commons.collections.map.AbstractReferenceMap$ReferenceEntrySetIterator.hasNext(AbstractReferenceMap.java:735) > at > org.apache.commons.collections.map.AbstractReferenceMap$ReferenceValues.toArray(AbstractReferenceMap.java:543) > at java.util.Collections$UnmodifiableCollection.toArray(Unknown Source) > at java.util.Collections$UnmodifiableCollection.toArray(Unknown Source) > at > org.apache.jackrabbit.core.state.LocalItemStateManager.dispose(LocalItemStateManager.java:341) > at > org.apache.jackrabbit.core.state.SessionItemStateManager.dispose(SessionItemStateManager.java:316) > at org.apache.jackrabbit.core.SessionImpl.logout(SessionImpl.java:1269) > at org.apache.jackrabbit.core.XASessionImpl.logout(XASessionImpl.java:379) > at > org.apache.jackrabbit.core.AbstractConcurrencyTest$Executor.run(AbstractConcurrencyTest.java:114) > at java.lang.Thread.run(Unknown Source) > Exception in thread "Thread-9" java.util.ConcurrentModificationException > at > org.apache.commons.collections.map.AbstractReferenceMap$ReferenceEntrySetIterator.checkMod(AbstractReferenceMap.java:761) > at > org.apache.commons.collections.map.AbstractReferenceMap$ReferenceEntrySetIterator.nextEntry(AbstractReferenceMap.java:770) > at > org.apache.commons.collections.map.AbstractReferenceMap$ReferenceValuesIterator.next(AbstractReferenceMap.java:829) > at > org.apache.commons.collections.map.AbstractReferenceMap$ReferenceValues.toArray(AbstractReferenceMap.java:544) > at java.util.Collections$UnmodifiableCollection.toArray(Unknown Source) > at java.util.Collections$UnmodifiableCollection.toArray(Unknown Source) > at > org.apache.jackrabbit.core.state.LocalItemStateManager.dispose(LocalItemStateManager.java:341) > at > org.apache.jackrabbit.core.state.SessionItemStateManager.dispose(SessionItemStateManager.java:316) > at org.apache.jackrabbit.core.SessionImpl.logout(SessionImpl.java:1269) > at > org.apache.jackrabbit.core.XASessionImpl.logout(XASessionImpl.java:379) > at > org.apache.jackrabbit.core.AbstractConcurrencyTest$Executor.run(AbstractConcurrencyTest.java:114) > at java.lang.Thread.run(Unknown Source) > My working copy is revision 538918 with both JCR-314 patches applied, using > FineGrainedISMLocking strategy. > I run this test manually from within Eclipse 3.2.1 / JRE 1.5.0_10-b03. > The workstation were I run this test has an Intel Dual-Core Xeon 5130 2 GHz. > To able to compare this CPU with another, with the default params of this > test (NUM_NODES = 5, NUM_THREADS = 5, RUN_NUM_SECONDS = 20), the number of > operations are ~ #writes performed: 300-400, #reads performed: 470 - > 490. > Regards, > Pablo -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-935) ConcurrentModificationException during logout (cont'd)
[ https://issues.apache.org/jira/browse/JCR-935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12524579 ] Esteban Franqueiro commented on JCR-935: Regarding the NPE that Pablo mentioned, it looks like a race condition, because the code first checks for != null, and then you get an NPE. The problem seems to disappear by synchronizing the pull(), connect(), reconnect(), disconnect(), isConnected(), isStale() and hasOverlayedState() methods. According to the results of the test Pablo mentioned, it seems that sync'ing these methods doesn't add too much serialization. Still. we're wondering what do you all think about this, because although it works in the test, we don't know if there's a better (or may be correct) way of solving this issue. Regards, Esteban > ConcurrentModificationException during logout (cont'd) > -- > > Key: JCR-935 > URL: https://issues.apache.org/jira/browse/JCR-935 > Project: Jackrabbit > Issue Type: Bug > Components: core >Affects Versions: 1.3 >Reporter: Pablo Rios > > I "seldom" get a CME running ConcurrentReadWriteTest.testReadWrite test. > Following are different stack traces of two runs: > > Exception in thread "Thread-9" java.util.ConcurrentModificationException > at > org.apache.commons.collections.map.AbstractReferenceMap$ReferenceEntrySetIterator.checkMod(AbstractReferenceMap.java:761) > at > org.apache.commons.collections.map.AbstractReferenceMap$ReferenceEntrySetIterator.hasNext(AbstractReferenceMap.java:735) > at > org.apache.commons.collections.map.AbstractReferenceMap$ReferenceValues.toArray(AbstractReferenceMap.java:543) > at java.util.Collections$UnmodifiableCollection.toArray(Unknown Source) > at java.util.Collections$UnmodifiableCollection.toArray(Unknown Source) > at > org.apache.jackrabbit.core.state.LocalItemStateManager.dispose(LocalItemStateManager.java:341) > at > org.apache.jackrabbit.core.state.SessionItemStateManager.dispose(SessionItemStateManager.java:316) > at org.apache.jackrabbit.core.SessionImpl.logout(SessionImpl.java:1269) > at org.apache.jackrabbit.core.XASessionImpl.logout(XASessionImpl.java:379) > at > org.apache.jackrabbit.core.AbstractConcurrencyTest$Executor.run(AbstractConcurrencyTest.java:114) > at java.lang.Thread.run(Unknown Source) > Exception in thread "Thread-9" java.util.ConcurrentModificationException > at > org.apache.commons.collections.map.AbstractReferenceMap$ReferenceEntrySetIterator.checkMod(AbstractReferenceMap.java:761) > at > org.apache.commons.collections.map.AbstractReferenceMap$ReferenceEntrySetIterator.nextEntry(AbstractReferenceMap.java:770) > at > org.apache.commons.collections.map.AbstractReferenceMap$ReferenceValuesIterator.next(AbstractReferenceMap.java:829) > at > org.apache.commons.collections.map.AbstractReferenceMap$ReferenceValues.toArray(AbstractReferenceMap.java:544) > at java.util.Collections$UnmodifiableCollection.toArray(Unknown Source) > at java.util.Collections$UnmodifiableCollection.toArray(Unknown Source) > at > org.apache.jackrabbit.core.state.LocalItemStateManager.dispose(LocalItemStateManager.java:341) > at > org.apache.jackrabbit.core.state.SessionItemStateManager.dispose(SessionItemStateManager.java:316) > at org.apache.jackrabbit.core.SessionImpl.logout(SessionImpl.java:1269) > at > org.apache.jackrabbit.core.XASessionImpl.logout(XASessionImpl.java:379) > at > org.apache.jackrabbit.core.AbstractConcurrencyTest$Executor.run(AbstractConcurrencyTest.java:114) > at java.lang.Thread.run(Unknown Source) > My working copy is revision 538918 with both JCR-314 patches applied, using > FineGrainedISMLocking strategy. > I run this test manually from within Eclipse 3.2.1 / JRE 1.5.0_10-b03. > The workstation were I run this test has an Intel Dual-Core Xeon 5130 2 GHz. > To able to compare this CPU with another, with the default params of this > test (NUM_NODES = 5, NUM_THREADS = 5, RUN_NUM_SECONDS = 20), the number of > operations are ~ #writes performed: 300-400, #reads performed: 470 - > 490. > Regards, > Pablo -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (JCR-926) Global data store for binaries
[ https://issues.apache.org/jira/browse/JCR-926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510720 ] Esteban Franqueiro commented on JCR-926: Thomas, your patch references org.apache.jackrabbit.benchmark.RandomInputStream, wich is not included in the patch, and I couldn't find it anywhere. Regards > Global data store for binaries > -- > > Key: JCR-926 > URL: https://issues.apache.org/jira/browse/JCR-926 > Project: Jackrabbit > Issue Type: New Feature > Components: core >Reporter: Jukka Zitting > Attachments: dataStore.patch, DataStore.patch, DataStore2.patch, > dataStore3.patch, dataStore4.zip, internalValue.patch, ReadWhileSaveTest.patch > > > There are three main problems with the way Jackrabbit currently handles large > binary values: > 1) Persisting a large binary value blocks access to the persistence layer for > extended amounts of time (see JCR-314) > 2) At least two copies of binary streams are made when saving them through > the JCR API: one in the transient space, and one when persisting the value > 3) Versioining and copy operations on nodes or subtrees that contain large > binary values can quickly end up consuming excessive amounts of storage space. > To solve these issues (and to get other nice benefits), I propose that we > implement a global "data store" concept in the repository. A data store is an > append-only set of binary values that uses short identifiers to identify and > access the stored binary values. The data store would trivially fit the > requirements of transient space and transaction handling due to the > append-only nature. An explicit mark-and-sweep garbage collection process > could be added to avoid concerns about storing garbage values. > See the recent NGP value record discussion, especially [1], for more > background on this idea. > [1] > http://mail-archives.apache.org/mod_mbox/jackrabbit-dev/200705.mbox/[EMAIL > PROTECTED] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
