You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Apache Jenkins Server <je...@builds.apache.org> on 2011/11/24 23:52:48 UTC
Jackrabbit-trunk - Build # 1754 - Still Unstable
The Apache Jenkins build system has built Jackrabbit-trunk (build #1754)
Status: Still Unstable
Check console output at https://builds.apache.org/job/Jackrabbit-trunk/1754/ to view the results.
Jackrabbit-trunk - Build # 1758 - Still Unstable
Posted by Apache Jenkins Server <je...@builds.apache.org>.
The Apache Jenkins build system has built Jackrabbit-trunk (build #1758)
Status: Still Unstable
Check console output at https://builds.apache.org/job/Jackrabbit-trunk/1758/ to view the results.
Jackrabbit-trunk - Build # 1757 - Still Unstable
Posted by Apache Jenkins Server <je...@builds.apache.org>.
The Apache Jenkins build system has built Jackrabbit-trunk (build #1757)
Status: Still Unstable
Check console output at https://builds.apache.org/job/Jackrabbit-trunk/1757/ to view the results.
Re: Jackrabbit-trunk - Build # 1756 - Still Unstable
Posted by Julian Reschke <ju...@gmx.de>.
On 2011-11-28 13:30, Apache Jenkins Server wrote:
> The Apache Jenkins build system has built Jackrabbit-trunk (build #1756)
>
> Status: Still Unstable
>
> Check console output at https://builds.apache.org/job/Jackrabbit-trunk/1756/ to view the results.
So, this includes query tests failing in jcr2spi. It appears these are
caused by earlier problems; when I rm ./target and do mvn clean install
in this subproject, the problems go away.
Best regards, Julian
Jackrabbit-trunk - Build # 1756 - Still Unstable
Posted by Apache Jenkins Server <je...@builds.apache.org>.
The Apache Jenkins build system has built Jackrabbit-trunk (build #1756)
Status: Still Unstable
Check console output at https://builds.apache.org/job/Jackrabbit-trunk/1756/ to view the results.
Re: Jackrabbit-trunk - Build # 1755 - Still Unstable
Posted by Angela Schreiber <an...@adobe.com>.
On 11/25/11 2:46 PM, Alex Parvulescu wrote:
> ok, continuing
>
> After studying the neighboring tests, namely inspired by
> AccessControlImporterTest#testImportRepoACLAtTestNode
>
> I think the fix is as simple as adding the missing acl repo info to the
> root node to #testImportRepoACLAtRoot:
> target.addMixin("rep:RepoAccessControllable");
the mixin should be added automatically.
i will take a closer look at it
angela
Re: Jackrabbit-trunk - Build # 1755 - Still Unstable
Posted by Alex Parvulescu <al...@gmail.com>.
Hi,
You mean it seems always *not* protected, right?
def.setProtected(false);
How can SessionImporter (line 316 startNode) [0] ever work then?
Is there something I'm missing?
alex
[0]
http://svn.apache.org/repos/asf/jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/xml/SessionImporter.java
On Fri, Nov 25, 2011 at 7:21 PM, Michael Dürig <md...@apache.org> wrote:
>
> It seems to be always protected:
>
> private static QNodeDefinition createRootNodeDef() {
> QNodeDefinitionBuilder def = new QNodeDefinitionBuilder();
>
> // FIXME need a fake declaring node type:
> // rep:root is not quite correct but better than a non-existing node
> type
> def.setDeclaringNodeType(**NameConstants.REP_ROOT);
> def.setRequiredPrimaryTypes(**new Name[]{NameConstants.REP_ROOT}**);
> def.setDefaultPrimaryType(**NameConstants.REP_ROOT);
> def.setMandatory(true);
> def.setProtected(false);
> def.setOnParentVersion(**OnParentVersionAction.VERSION)**;
> def.setAllowsSameNameSiblings(**false);
> def.setAutoCreated(true);
> return def.build();
> }
>
> NodeTypeRegistry:1808
>
> Michael
>
>
> On 25.11.11 16:36, Alex Parvulescu wrote:
>
>> ok, I kinda lost here
>>
>> any ideas how the root node can be sometimes protected?
>>
>> http://www.day.com/maven/**javax.jcr/javadocs/jcr-2.0/**
>> javax/jcr/nodetype/**ItemDefinition.html#**isProtected()<http://www.day.com/maven/javax.jcr/javadocs/jcr-2.0/javax/jcr/nodetype/ItemDefinition.html#isProtected()>
>> http://www.day.com/specs/jcr/**2.0/3_Repository_Model.html#3.**7.2.2<http://www.day.com/specs/jcr/2.0/3_Repository_Model.html#3.7.2.2>Protected
>>
>> alex
>>
>> On Fri, Nov 25, 2011 at 5:30 PM, Alex Parvulescu
>> <alex.parvulescu@gmail.com <ma...@gmail.com>>>
>> wrote:
>>
>> > Sounds right, though I'm not sure if the importer from JCR-3152
>> should take care of adding that mixin automatically.
>>
>> Good point, I went into that a bit, and it seems that the importer
>> (AccessControlImporter) *may* do that in the #start method (which
>> never gets called).
>>
>> The reason can be found under SessionImporter#startNode:
>> if (parent.getDefinition().**isProtected())
>>
>> Here parent is the root node, which seems to fail the test thus
>> makin the SessionImporter skip the vital #start call.
>> Indeed checking sImpl.getRootNode().**getDefinition().isProtected()
>> yields false within the test context.
>>
>> alex
>>
>> On Fri, Nov 25, 2011 at 4:11 PM, Alex Parvulescu
>> <alex.parvulescu@gmail.com <ma...@gmail.com>>>
>> wrote:
>>
>> I can't get it to pass anymore:
>>
>> By running
>> rm -rf target; mvn -Dtest=**AccessControlImporterTest clean
>> test
>> on jackrabbit-core (a fresh trunk checkout)
>>
>> It fails every time:
>>
>> --------
>> Running org.apache.jackrabbit.core.**xml.AccessControlImporterTest
>> Tests run: 13, Failures: 1, Errors: 1, Skipped: 0, Time elapsed:
>> 14.925 sec <<< FAILURE!
>>
>> Results :
>>
>> Failed tests:
>> testImportRepoACLAtRoot(org.**apache.jackrabbit.core.xml.**
>> AccessControlImporterTest):
>> expected:<1> but was:<0>
>>
>> Tests in error:
>>
>> testImportPrincipalBasedACL(**org.apache.jackrabbit.core.**
>> xml.AccessControlImporterTest)**:
>> Authorizable for 'administrators' already exists:
>>
>> Tests run: 13, Failures: 1, Errors: 1, Skipped: 0
>> --------
>>
>> It is probably related to running the tests concurrently
>> (JCR-3152 mentions that as well).
>>
>> alex
>>
>> On Fri, Nov 25, 2011 at 3:47 PM, Alex Parvulescu
>> <alex.parvulescu@gmail.com <ma...@gmail.com>
>> >>
>>
>> wrote:
>>
>> Good question, I don't know what are the assumptions about
>> the root node having some special acl properties.
>>
>> I've only seen the last 3 builds fail because of that. It
>> apparently is a deeper issue. Maybe the proposed fix is not
>> a good idea.
>>
>> alex
>>
>> On Fri, Nov 25, 2011 at 3:32 PM, Jukka Zitting
>> <jukka.zitting@gmail.com <ma...@gmail.com>
>> >>
>>
>> wrote:
>>
>> Hi,
>>
>> On Fri, Nov 25, 2011 at 2:46 PM, Alex Parvulescu
>> <alex.parvulescu@gmail.com
>> <ma...@gmail.com>>>
>> wrote:
>> > After studying the neighboring tests, namely inspired by
>> > AccessControlImporterTest#**testImportRepoACLAtTestNode
>> > I think the fix is as simple as adding the missing
>> acl repo info to the root
>> > node to #testImportRepoACLAtRoot:
>> > target.addMixin("rep:**RepoAccessControllable");
>>
>> Sounds right, though I'm not sure if the importer from
>> JCR-3152 should
>> take care of adding that mixin automatically.
>>
>> I encountered the same issue before cutting the 2.3.4
>> release
>> candidate and came to the same conclusion that the
>> rep:RepoAccessControllable mixin is not present. Since
>> the problem
>> doesn't occur consistently across builds I thought that
>> it was due to
>> some test ordering issue. I fixed the test execution
>> order in revision
>> 1205866 which seemed to have solved the issue for me,
>> but apparently
>> that was just a coincidence.
>>
>> I wonder if we're still missing something. Why does the
>> test pass
>> sometimes without the proposed fix?
>>
>> BR,
>>
>> Jukka Zitting
>>
>>
>>
>>
>>
>>
Re: Jackrabbit-trunk - Build # 1755 - Still Unstable
Posted by Michael Dürig <md...@apache.org>.
It seems to be always protected:
private static QNodeDefinition createRootNodeDef() {
QNodeDefinitionBuilder def = new QNodeDefinitionBuilder();
// FIXME need a fake declaring node type:
// rep:root is not quite correct but better than a non-existing
node type
def.setDeclaringNodeType(NameConstants.REP_ROOT);
def.setRequiredPrimaryTypes(new Name[]{NameConstants.REP_ROOT});
def.setDefaultPrimaryType(NameConstants.REP_ROOT);
def.setMandatory(true);
def.setProtected(false);
def.setOnParentVersion(OnParentVersionAction.VERSION);
def.setAllowsSameNameSiblings(false);
def.setAutoCreated(true);
return def.build();
}
NodeTypeRegistry:1808
Michael
On 25.11.11 16:36, Alex Parvulescu wrote:
> ok, I kinda lost here
>
> any ideas how the root node can be sometimes protected?
>
> http://www.day.com/maven/javax.jcr/javadocs/jcr-2.0/javax/jcr/nodetype/ItemDefinition.html#isProtected()
> http://www.day.com/specs/jcr/2.0/3_Repository_Model.html#3.7.2.2 Protected
>
> alex
>
> On Fri, Nov 25, 2011 at 5:30 PM, Alex Parvulescu
> <alex.parvulescu@gmail.com <ma...@gmail.com>> wrote:
>
> > Sounds right, though I'm not sure if the importer from JCR-3152
> should take care of adding that mixin automatically.
>
> Good point, I went into that a bit, and it seems that the importer
> (AccessControlImporter) *may* do that in the #start method (which
> never gets called).
>
> The reason can be found under SessionImporter#startNode:
> if (parent.getDefinition().isProtected())
>
> Here parent is the root node, which seems to fail the test thus
> makin the SessionImporter skip the vital #start call.
> Indeed checking sImpl.getRootNode().getDefinition().isProtected()
> yields false within the test context.
>
> alex
>
> On Fri, Nov 25, 2011 at 4:11 PM, Alex Parvulescu
> <alex.parvulescu@gmail.com <ma...@gmail.com>> wrote:
>
> I can't get it to pass anymore:
>
> By running
> rm -rf target; mvn -Dtest=AccessControlImporterTest clean test
> on jackrabbit-core (a fresh trunk checkout)
>
> It fails every time:
>
> --------
> Running org.apache.jackrabbit.core.xml.AccessControlImporterTest
> Tests run: 13, Failures: 1, Errors: 1, Skipped: 0, Time elapsed:
> 14.925 sec <<< FAILURE!
>
> Results :
>
> Failed tests:
> testImportRepoACLAtRoot(org.apache.jackrabbit.core.xml.AccessControlImporterTest):
> expected:<1> but was:<0>
>
> Tests in error:
>
> testImportPrincipalBasedACL(org.apache.jackrabbit.core.xml.AccessControlImporterTest):
> Authorizable for 'administrators' already exists:
>
> Tests run: 13, Failures: 1, Errors: 1, Skipped: 0
> --------
>
> It is probably related to running the tests concurrently
> (JCR-3152 mentions that as well).
>
> alex
>
> On Fri, Nov 25, 2011 at 3:47 PM, Alex Parvulescu
> <alex.parvulescu@gmail.com <ma...@gmail.com>>
> wrote:
>
> Good question, I don't know what are the assumptions about
> the root node having some special acl properties.
>
> I've only seen the last 3 builds fail because of that. It
> apparently is a deeper issue. Maybe the proposed fix is not
> a good idea.
>
> alex
>
> On Fri, Nov 25, 2011 at 3:32 PM, Jukka Zitting
> <jukka.zitting@gmail.com <ma...@gmail.com>>
> wrote:
>
> Hi,
>
> On Fri, Nov 25, 2011 at 2:46 PM, Alex Parvulescu
> <alex.parvulescu@gmail.com
> <ma...@gmail.com>> wrote:
> > After studying the neighboring tests, namely inspired by
> > AccessControlImporterTest#testImportRepoACLAtTestNode
> > I think the fix is as simple as adding the missing
> acl repo info to the root
> > node to #testImportRepoACLAtRoot:
> > target.addMixin("rep:RepoAccessControllable");
>
> Sounds right, though I'm not sure if the importer from
> JCR-3152 should
> take care of adding that mixin automatically.
>
> I encountered the same issue before cutting the 2.3.4
> release
> candidate and came to the same conclusion that the
> rep:RepoAccessControllable mixin is not present. Since
> the problem
> doesn't occur consistently across builds I thought that
> it was due to
> some test ordering issue. I fixed the test execution
> order in revision
> 1205866 which seemed to have solved the issue for me,
> but apparently
> that was just a coincidence.
>
> I wonder if we're still missing something. Why does the
> test pass
> sometimes without the proposed fix?
>
> BR,
>
> Jukka Zitting
>
>
>
>
>
Re: too many open files / derby / suse
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Mon, Nov 28, 2011 at 1:17 PM, ulf schneider <us...@datenlabor.net> wrote:
> do you have recommendations how to deal with this issue?
The simple solution is to increase the limit on open files.
BR,
Jukka Zitting
Re: too many open files / derby / suse
Posted by ulf schneider <us...@datenlabor.net>.
thomas,
doing lsof -u tomcat i find a list of open files like the one below for each workspace.
i think that is expected for derby and is conform to what you explained. in addition tomcat has open files to the jars that are needed and i do not see any suspicious files so i will leave it for now like it is and check again later.
regards, ulf.
java 3045 tomcat 576u REG 3,7 1048576 134580311 /srv/docker/workspaces/AWK314/db/log/log4.dat
java 3045 tomcat 577uw REG 3,7 4 101034512 /srv/docker/workspaces/AWK314/db/dbex.lck
java 3045 tomcat 578u REG 3,7 8192 152017578 /srv/docker/workspaces/AWK314/db/seg0/c10.dat
java 3045 tomcat 579u REG 3,7 8192 152017597 /srv/docker/workspaces/AWK314/db/seg0/cc0.dat
java 3045 tomcat 580u REG 3,7 8192 152017598 /srv/docker/workspaces/AWK314/db/seg0/cd1.dat
java 3045 tomcat 581u REG 3,7 8192 152017590 /srv/docker/workspaces/AWK314/db/seg0/c60.dat
java 3045 tomcat 582u REG 3,7 8192 152017591 /srv/docker/workspaces/AWK314/db/seg0/c71.dat
java 3045 tomcat 583u REG 3,7 20480 152017593 /srv/docker/workspaces/AWK314/db/seg0/c90.dat
java 3045 tomcat 584u REG 3,7 24576 152017594 /srv/docker/workspaces/AWK314/db/seg0/ca1.dat
java 3045 tomcat 585u REG 3,7 28672 152017583 /srv/docker/workspaces/AWK314/db/seg0/c20.dat
java 3045 tomcat 586u REG 3,7 8192 152017589 /srv/docker/workspaces/AWK314/db/seg0/c51.dat
java 3045 tomcat 587u REG 3,7 245760 152017425 /srv/docker/workspaces/AWK314/db/seg0/c230.dat
java 3045 tomcat 588u REG 3,7 24576 152017426 /srv/docker/workspaces/AWK314/db/seg0/c241.dat
java 3045 tomcat 589u REG 3,7 16384 152017427 /srv/docker/workspaces/AWK314/db/seg0/c251.dat
java 3045 tomcat 590u REG 3,7 8192 152017408 /srv/docker/workspaces/AWK314/db/seg0/c150.dat
java 3045 tomcat 591u REG 3,7 8192 152017409 /srv/docker/workspaces/AWK314/db/seg0/c161.dat
java 3045 tomcat 592u REG 3,7 8192 152017435 /srv/docker/workspaces/AWK314/db/seg0/c2d0.dat
java 3045 tomcat 593u REG 3,7 8192 152017436 /srv/docker/workspaces/AWK314/db/seg0/c2e1.dat
java 3045 tomcat 594u REG 3,7 8192 152017592 /srv/docker/workspaces/AWK314/db/seg0/c81.dat
java 3045 tomcat 595u REG 3,7 8192 152017599 /srv/docker/workspaces/AWK314/db/seg0/ce1.dat
java 3045 tomcat 596u REG 3,7 32768 152017414 /srv/docker/workspaces/AWK314/db/seg0/c180.dat
java 3045 tomcat 597u REG 3,7 16384 152017415 /srv/docker/workspaces/AWK314/db/seg0/c191.dat
java 3045 tomcat 598u REG 3,7 131072 152021397 /srv/docker/workspaces/AWK314/db/seg0/c400.dat
java 3045 tomcat 599u REG 3,7 16384 152021398 /srv/docker/workspaces/AWK314/db/seg0/c411.dat
java 3045 tomcat 600u REG 3,7 8192 152017382 /srv/docker/workspaces/AWK314/db/seg0/cf0.dat
java 3045 tomcat 601u REG 3,7 8192 152017405 /srv/docker/workspaces/AWK314/db/seg0/c121.dat
java 3045 tomcat 602u REG 3,7 8192 152017406 /srv/docker/workspaces/AWK314/db/seg0/c130.dat
java 3045 tomcat 603u REG 3,7 8192 152017407 /srv/docker/workspaces/AWK314/db/seg0/c141.dat
java 3045 tomcat 604r REG 3,7 133707 168906123 /srv/docker/workspaces/AWK314/index/_5q/_0.cfs
java 3045 tomcat 605r REG 3,7 133707 168906123 /srv/docker/workspaces/AWK314/index/_5q/_0.cfs
--
ulf schneider
+49 163 2505164
mail: us@datenlabor.net
blog: http://allesagil.net
datenlabor gmbh
sitz: paderborn, hrb 8819
geschäftsführer: ulf schneider
http://datenlabor.net
Am 28.11.2011 um 15:25 schrieb Thomas Mueller:
> Hi,
>
>> and as far as i can see the failure is gone.
>
> Depending on what the problem is, that might only be a temporary solution.
> I really would try to find out what the problem is, using "lsof -p <pid>".
> To get the pid, use "jps -l".
>
>> @thomas: you suggested to use H2. would it be possible to replace derby
>> with H2 but reuse the file structure that has already been created by
>> derby?
>
> H2 only needs one file per database (plus one temporary file to lock the
> database file, plus possibly a log file). Derby uses many files per
> database (one per table or index, plus a few for the transaction log, and
> so on). So: no. You need to create a new database / new databases.
>
> Regards,
> Thomas
>
Re: too many open files / derby / suse
Posted by Thomas Mueller <mu...@adobe.com>.
Hi,
>and as far as i can see the failure is gone.
Depending on what the problem is, that might only be a temporary solution.
I really would try to find out what the problem is, using "lsof -p <pid>".
To get the pid, use "jps -l".
>@thomas: you suggested to use H2. would it be possible to replace derby
>with H2 but reuse the file structure that has already been created by
>derby?
H2 only needs one file per database (plus one temporary file to lock the
database file, plus possibly a log file). Derby uses many files per
database (one per table or index, plus a few for the transaction log, and
so on). So: no. You need to create a new database / new databases.
Regards,
Thomas
Re: too many open files / derby / suse
Posted by ulf schneider <us...@datenlabor.net>.
yukka and thomas,
thanks a lot for your help. i've configured
/etc/security/limits.conf
* soft nofile 10240
* hard nofile 10240
and as far as i can see the failure is gone.
@thomas: you suggested to use H2. would it be possible to replace derby with H2 but reuse the file structure that has already been created by derby?
--
ulf schneider
+49 163 2505164
mail: us@datenlabor.net
blog: http://allesagil.net
datenlabor gmbh
sitz: paderborn, hrb 8819
geschäftsführer: ulf schneider
http://datenlabor.net
Am 28.11.2011 um 13:23 schrieb Thomas Mueller:
> Hi,
>
> Could you run "lsof" to find out what files are open? I guess most files
> are open in a different area (not Derby). If it really is Derby, then an
> option is to use another database, for example H2 (disclaimer: I'm one of
> the committers of H2).
>
> Regards,
> Thomas
>
>
> On 11/28/11 1:17 PM, "ulf schneider" <us...@datenlabor.net> wrote:
>
>> dear developers,
>> i'm running a jackrabbit system with several workspaces (15) and using
>> derby as embedded database on suse linux.
>> since a few days and after adding another workspace i get exceptions like
>> the one that i've attached to this e-mail (reproducable with jackrabbit
>> 2.2.9 and 2.2.10). i'm suspecting that the failure is originated by the
>> number of workspaces.
>> ulimit -n prints out a value of 1024.
>>
>> do you have recommendations how to deal with this issue?
>>
>> best regards, ulf.
>>
>>
>> 2011.11.27 13:11:00.087 ERROR [DbUtility.java:92] failed to close
>> Connection
>> 2011.11.27 13:11:00.087 ERROR [DbUtility.java:94] Reason: Already
>> closed.
>> 2011.11.27 13:11:00.088 ERROR [DbUtility.java:95] State/Code: null/0
>> 2011.11.27 13:11:00.095 ERROR [ConnectionHelper.java:498] Failed to
>> execute SQL (stacktrace on DEBUG log level)
>> org.apache.commons.dbcp.SQLNestedException: Borrow prepareStatement from
>> pool failed
>> at
>> org.apache.commons.dbcp.PoolingConnection.prepareStatement(PoolingConnecti
>> on.java:98) ~[commons-dbcp-1.2.2.jar:1.2.2]
>> at
>> org.apache.commons.dbcp.DelegatingConnection.prepareStatement(DelegatingCo
>> nnection.java:248) ~[commons-dbcp-1.2.2.jar:1.2.2]
>> at
>> org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.prepa
>> reStatement(PoolingDataSource.java:302) ~[commons-dbcp-1.2.2.jar:1.2.2]
>> at
>> org.apache.jackrabbit.core.util.db.ConnectionHelper.reallyExec(ConnectionH
>> elper.java:387) [jackrabbit-core-2.2.10.jar:2.2.10]
>> at
>> org.apache.jackrabbit.core.util.db.ConnectionHelper$3.call(ConnectionHelpe
>> r.java:371) ~[jackrabbit-core-2.2.10.jar:2.2.10]
>> at
>> org.apache.jackrabbit.core.util.db.ConnectionHelper$3.call(ConnectionHelpe
>> r.java:367) ~[jackrabbit-core-2.2.10.jar:2.2.10]
>> at
>> org.apache.jackrabbit.core.util.db.ConnectionHelper$RetryManager.doTry(Con
>> nectionHelper.java:494) ~[jackrabbit-core-2.2.10.jar:2.2.10]
>> at
>> org.apache.jackrabbit.core.util.db.ConnectionHelper.exec(ConnectionHelper.
>> java:367) [jackrabbit-core-2.2.10.jar:2.2.10]
>> at
>> org.apache.jackrabbit.core.persistence.pool.BundleDbPersistenceManager.loa
>> dReferencesTo(BundleDbPersistenceManager.java:1141)
>> [jackrabbit-core-2.2.10.jar:2.2.10]
>> at
>> org.apache.jackrabbit.core.state.SharedItemStateManager.getNodeReferences(
>> SharedItemStateManager.java:335) [jackrabbit-core-2.2.10.jar:2.2.10]
>> at
>> org.apache.jackrabbit.core.state.LocalItemStateManager.getNodeReferences(L
>> ocalItemStateManager.java:218) [jackrabbit-core-2.2.10.jar:2.2.10]
>> at
>> org.apache.jackrabbit.core.state.XAItemStateManager.getReferences(XAItemSt
>> ateManager.java:372) [jackrabbit-core-2.2.10.jar:2.2.10]
>> at
>> org.apache.jackrabbit.core.state.XAItemStateManager.hasNodeReferences(XAIt
>> emStateManager.java:335) [jackrabbit-core-2.2.10.jar:2.2.10]
>> at
>> org.apache.jackrabbit.core.state.SessionItemStateManager.hasNodeReferences
>> (SessionItemStateManager.java:198) [jackrabbit-core-2.2.10.jar:2.2.10]
>> at
>> org.apache.jackrabbit.core.NodeImpl.getReferences(NodeImpl.java:3028)
>> [jackrabbit-core-2.2.10.jar:2.2.10]
>> at
>> org.apache.jackrabbit.core.NodeImpl.getReferences(NodeImpl.java:2406)
>> [jackrabbit-core-2.2.10.jar:2.2.10]
>> at
>> dlab.content.ocm.OCMStorer.removeTaggingReferences(OCMStorer.java:459)
>> [dlab_content_1.4.2.jar:na]
>> at dlab.content.ocm.OCMStorer.storeTagging(OCMStorer.java:1064)
>> [dlab_content_1.4.2.jar:na]
>> at
>> dlab.content.ocm.OCMStorer.storeFinalProperty(OCMStorer.java:789)
>> [dlab_content_1.4.2.jar:na]
>> at
>> dlab.content.ocm.ObjectContentMapperJsr170.traverseAndStoreObject(ObjectCo
>> ntentMapperJsr170.java:1025) [dlab_content_1.4.2.jar:na]
>> at
>> dlab.content.ocm.ObjectContentMapperJsr170.traverseAndStoreObject(ObjectCo
>> ntentMapperJsr170.java:1066) [dlab_content_1.4.2.jar:na]
>> at
>> dlab.content.ocm.ObjectContentMapperJsr170.setContent(ObjectContentMapperJ
>> sr170.java:698) [dlab_content_1.4.2.jar:na]
>> at
>> dlab.content.ocm.ObjectContentMapperJsr170.setContent(ObjectContentMapperJ
>> sr170.java:710) [dlab_content_1.4.2.jar:na]
>> at
>> dlab.content.service.ContentService.storeContent(ContentService.java:2908)
>> [dlab_content_1.4.2.jar:na]
>> at
>> dlab.content.service.ContentService.storeContent(ContentService.java:2859)
>> [dlab_content_1.4.2.jar:na]
>> at
>> dlab.docker.document.DocumentEditablePage.store(DocumentEditablePage.java:
>> 608) [dlab_docker_templating_1.4.2.jar:na]
>> at
>> dlab.docker.document.DocumentEditablePage.onSubmit(DocumentEditablePage.ja
>> va:510) [dlab_docker_templating_1.4.2.jar:na]
>> at
>> dlab.web.dialog.DialogEditablePage$1.onSubmit(DialogEditablePage.java:116)
>> [dlab_web_1.4.2.jar:na]
>> at
>> org.apache.wicket.markup.html.form.Form$10.component(Form.java:1189)
>> [wicket-core-1.5.3.jar:1.5.3]
>> at
>> org.apache.wicket.markup.html.form.Form$10.component(Form.java:1184)
>> [wicket-core-1.5.3.jar:1.5.3]
>> at
>> org.apache.wicket.util.visit.Visits.visitPostOrderHelper(Visits.java:273)
>> [wicket-util-1.5.3.jar:1.5.3]
>> at
>> org.apache.wicket.util.visit.Visits.visitPostOrder(Visits.java:244)
>> [wicket-util-1.5.3.jar:1.5.3]
>> at
>> org.apache.wicket.markup.html.form.Form.delegateSubmit(Form.java:1182)
>> [wicket-core-1.5.3.jar:1.5.3]
>> at org.apache.wicket.markup.html.form.Form.process(Form.java:838)
>> [wicket-core-1.5.3.jar:1.5.3]
>> at
>> org.apache.wicket.markup.html.form.Form.onFormSubmitted(Form.java:762)
>> [wicket-core-1.5.3.jar:1.5.3]
>> at
>> org.apache.wicket.markup.html.form.Form.onFormSubmitted(Form.java:692)
>> [wicket-core-1.5.3.jar:1.5.3]
>> at sun.reflect.GeneratedMethodAccessor175.invoke(Unknown Source)
>> ~[na:na]
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorIm
>> pl.java:25) ~[na:1.6.0_17]
>> at java.lang.reflect.Method.invoke(Method.java:597) ~[na:1.6.0_17]
>> at
>> org.apache.wicket.RequestListenerInterface.internalInvoke(RequestListenerI
>> nterface.java:260) [wicket-core-1.5.3.jar:1.5.3]
>> at
>> org.apache.wicket.RequestListenerInterface.invoke(RequestListenerInterface
>> .java:216) [wicket-core-1.5.3.jar:1.5.3]
>> at
>> org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.invokeLi
>> stener(ListenerInterfaceRequestHandler.java:248)
>> [wicket-core-1.5.3.jar:1.5.3]
>> at
>> org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.respond(
>> ListenerInterfaceRequestHandler.java:234) [wicket-core-1.5.3.jar:1.5.3]
>> at
>> org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(Reque
>> stCycle.java:750) [wicket-core-1.5.3.jar:1.5.3]
>> at
>> org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.
>> java:64) [wicket-request-1.5.3.jar:1.5.3]
>> at
>> org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:252
>> ) [wicket-core-1.5.3.jar:1.5.3]
>> at
>> org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.j
>> ava:209) [wicket-core-1.5.3.jar:1.5.3]
>> at
>> org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(Reque
>> stCycle.java:280) [wicket-core-1.5.3.jar:1.5.3]
>> at
>> org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.j
>> ava:162) [wicket-core-1.5.3.jar:1.5.3]
>> at
>> org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:21
>> 8) [wicket-core-1.5.3.jar:1.5.3]
>> at
>> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicati
>> onFilterChain.java:235) [catalina-6.0.16.jar:na]
>> at
>> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilter
>> Chain.java:206) [catalina-6.0.16.jar:na]
>> at
>> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.
>> java:233) [catalina-6.0.16.jar:na]
>> at
>> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.
>> java:174) [catalina-6.0.16.jar:na]
>> at
>> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:1
>> 28) [catalina-6.0.16.jar:na]
>> at
>> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:1
>> 02) [catalina-6.0.16.jar:na]
>> at
>> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.ja
>> va:109) [catalina-6.0.16.jar:na]
>> at
>> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286
>> ) [catalina-6.0.16.jar:na]
>> at
>> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
>> [tomcat-coyote-6.0.16.jar:na]
>> at
>> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Ht
>> tp11Protocol.java:583) [tomcat-coyote-6.0.16.jar:na]
>> at
>> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
>> [tomcat-coyote-6.0.16.jar:na]
>> at java.lang.Thread.run(Thread.java:619) [na:1.6.0_17]
>> Caused by: java.sql.SQLException: Meta-data for Container
>> org.apache.derby.impl.store.raw.data.RAFContainer4@3e6e4eff could not be
>> accessed
>> at
>> org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown
>> Source) ~[derby-10.5.3.0_1.jar:na]
>> at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown
>> Source) ~[derby-10.5.3.0_1.jar:na]
>> at org.apache.derby.impl.jdbc.Util.seeNextException(Unknown
>> Source) ~[derby-10.5.3.0_1.jar:na]
>> at
>> org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unkn
>> own Source) ~[derby-10.5.3.0_1.jar:na]
>> at
>> org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown
>> Source) ~[derby-10.5.3.0_1.jar:na]
>> at
>> org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown
>> Source) ~[derby-10.5.3.0_1.jar:na]
>> at
>> org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown
>> Source) ~[derby-10.5.3.0_1.jar:na]
>> at
>> org.apache.derby.impl.jdbc.EmbedPreparedStatement.<init>(Unknown Source)
>> ~[derby-10.5.3.0_1.jar:na]
>> at
>> org.apache.derby.impl.jdbc.EmbedPreparedStatement20.<init>(Unknown
>> Source) ~[derby-10.5.3.0_1.jar:na]
>> at
>> org.apache.derby.impl.jdbc.EmbedPreparedStatement30.<init>(Unknown
>> Source) ~[derby-10.5.3.0_1.jar:na]
>> at
>> org.apache.derby.impl.jdbc.EmbedPreparedStatement40.<init>(Unknown
>> Source) ~[derby-10.5.3.0_1.jar:na]
>> at
>> org.apache.derby.jdbc.Driver40.newEmbedPreparedStatement(Unknown Source)
>> ~[derby-10.5.3.0_1.jar:na]
>> at
>> org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown
>> Source) ~[derby-10.5.3.0_1.jar:na]
>> at
>> org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown
>> Source) ~[derby-10.5.3.0_1.jar:na]
>> at
>> org.apache.commons.dbcp.PoolingConnection.makeObject(PoolingConnection.jav
>> a:193) ~[commons-dbcp-1.2.2.jar:1.2.2]
>> at
>> org.apache.commons.pool.impl.GenericKeyedObjectPool.borrowObject(GenericKe
>> yedObjectPool.java:797) ~[commons-pool-1.3.jar:1.3]
>> at
>> org.apache.commons.dbcp.PoolingConnection.prepareStatement(PoolingConnecti
>> on.java:92) ~[commons-dbcp-1.2.2.jar:1.2.2]
>> ... 61 common frames omitted
>> Caused by: org.apache.derby.impl.jdbc.EmbedSQLException: Meta-data for
>> Container org.apache.derby.impl.store.raw.data.RAFContainer4@3e6e4eff
>> could not be accessed
>> at
>> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown
>> Source) ~[derby-10.5.3.0_1.jar:na]
>> at
>> org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcros
>> sDRDA(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
>> ... 78 common frames omitted
>> Caused by: org.apache.derby.impl.jdbc.EmbedSQLException: Java exception:
>> '/srv/docker/workspaces/CRM/db/seg0/c3f1.dat (Too many open files):
>> java.io.FileNotFoundException'.
>> at
>> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown
>> Source) ~[derby-10.5.3.0_1.jar:na]
>> at
>> org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcros
>> sDRDA(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
>> at
>> org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown
>> Source) ~[derby-10.5.3.0_1.jar:na]
>> at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown
>> Source) ~[derby-10.5.3.0_1.jar:na]
>> at org.apache.derby.impl.jdbc.Util.javaException(Unknown Source)
>> ~[derby-10.5.3.0_1.jar:na]
>> at
>> org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unkn
>> own Source) ~[derby-10.5.3.0_1.jar:na]
>> ... 75 common frames omitted
>> Caused by: java.io.FileNotFoundException:
>> /srv/docker/workspaces/CRM/db/seg0/c3f1.dat (Too many open files)
>> at java.io.RandomAccessFile.open(Native Method) ~[na:1.6.0_17]
>> at java.io.RandomAccessFile.<init>(RandomAccessFile.java:212)
>> ~[na:1.6.0_17]
>> at org.apache.derby.impl.io.DirRandomAccessFile.<init>(Unknown
>> Source) ~[derby-10.5.3.0_1.jar:na]
>> at org.apache.derby.impl.io.DirRandomAccessFile4.<init>(Unknown
>> Source) ~[derby-10.5.3.0_1.jar:na]
>> at org.apache.derby.impl.io.DirFile4.getRandomAccessFile(Unknown
>> Source) ~[derby-10.5.3.0_1.jar:na]
>> at org.apache.derby.impl.store.raw.data.RAFContainer.run(Unknown
>> Source) ~[derby-10.5.3.0_1.jar:na]
>> at java.security.AccessController.doPrivileged(Native Method)
>> ~[na:1.6.0_17]
>> at
>> org.apache.derby.impl.store.raw.data.RAFContainer.openContainer(Unknown
>> Source) ~[derby-10.5.3.0_1.jar:na]
>> at
>> org.apache.derby.impl.store.raw.data.RAFContainer4.openContainer(Unknown
>> Source) ~[derby-10.5.3.0_1.jar:na]
>> at
>> org.apache.derby.impl.store.raw.data.FileContainer.setIdent(Unknown
>> Source) ~[derby-10.5.3.0_1.jar:na]
>> at
>> org.apache.derby.impl.store.raw.data.RAFContainer.setIdentity(Unknown
>> Source) ~[derby-10.5.3.0_1.jar:na]
>> at
>> org.apache.derby.impl.services.cache.ConcurrentCache.find(Unknown Source)
>> ~[derby-10.5.3.0_1.jar:na]
>> at
>> org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(Unk
>> nown Source) ~[derby-10.5.3.0_1.jar:na]
>> at
>> org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(Unk
>> nown Source) ~[derby-10.5.3.0_1.jar:na]
>> at
>> org.apache.derby.impl.store.raw.xact.Xact.openContainer(Unknown Source)
>> ~[derby-10.5.3.0_1.jar:na]
>> at
>> org.apache.derby.impl.store.access.btree.index.B2IFactory.readConglomerate
>> (Unknown Source) ~[derby-10.5.3.0_1.jar:na]
>> at
>> org.apache.derby.impl.store.access.RAMAccessManager.conglomCacheFind(Unkno
>> wn Source) ~[derby-10.5.3.0_1.jar:na]
>> at
>> org.apache.derby.impl.store.access.RAMTransaction.findExistingConglomerate
>> (Unknown Source) ~[derby-10.5.3.0_1.jar:na]
>> at
>> org.apache.derby.impl.store.access.RAMTransaction.openStoreCost(Unknown
>> Source) ~[derby-10.5.3.0_1.jar:na]
>> at
>> org.apache.derby.impl.sql.compile.CompilerContextImpl.getStoreCostControll
>> er(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
>> at
>> org.apache.derby.impl.sql.compile.FromBaseTable.getStoreCostController(Unk
>> nown Source) ~[derby-10.5.3.0_1.jar:na]
>> at
>> org.apache.derby.impl.sql.compile.FromBaseTable.estimateCost(Unknown
>> Source) ~[derby-10.5.3.0_1.jar:na]
>> at
>> org.apache.derby.impl.sql.compile.OptimizerImpl.estimateTotalCost(Unknown
>> Source) ~[derby-10.5.3.0_1.jar:na]
>> at
>> org.apache.derby.impl.sql.compile.OptimizerImpl.costBasedCostOptimizable(U
>> nknown Source) ~[derby-10.5.3.0_1.jar:na]
>> at
>> org.apache.derby.impl.sql.compile.OptimizerImpl.costOptimizable(Unknown
>> Source) ~[derby-10.5.3.0_1.jar:na]
>> at
>> org.apache.derby.impl.sql.compile.FromBaseTable.optimizeIt(Unknown
>> Source) ~[derby-10.5.3.0_1.jar:na]
>> at
>> org.apache.derby.impl.sql.compile.ProjectRestrictNode.optimizeIt(Unknown
>> Source) ~[derby-10.5.3.0_1.jar:na]
>> at
>> org.apache.derby.impl.sql.compile.OptimizerImpl.costPermutation(Unknown
>> Source) ~[derby-10.5.3.0_1.jar:na]
>> at org.apache.derby.impl.sql.compile.SelectNode.optimize(Unknown
>> Source) ~[derby-10.5.3.0_1.jar:na]
>> at
>> org.apache.derby.impl.sql.compile.DMLStatementNode.optimizeStatement(Unkno
>> wn Source) ~[derby-10.5.3.0_1.jar:na]
>> at
>> org.apache.derby.impl.sql.compile.CursorNode.optimizeStatement(Unknown
>> Source) ~[derby-10.5.3.0_1.jar:na]
>> at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown
>> Source) ~[derby-10.5.3.0_1.jar:na]
>> at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown
>> Source) ~[derby-10.5.3.0_1.jar:na]
>> at
>> org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInt
>> ernalStatement(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
>> ... 71 common frames omitted
>> --
>> ulf schneider
>> +49 163 2505164
>> mail: us@datenlabor.net
>> blog: http://allesagil.net
>>
>> datenlabor gmbh
>> sitz: paderborn, hrb 8819
>> geschäftsführer: ulf schneider
>> http://datenlabor.net
>>
>> Am 25.11.2011 um 18:01 schrieb Julian Reschke:
>>
>>> On 2011-11-25 17:36, Alex Parvulescu wrote:
>>>> ok, I kinda lost here
>>>>
>>>> any ideas how the root node can be sometimes protected?
>>>>
>>>>
>>>> http://www.day.com/maven/javax.jcr/javadocs/jcr-2.0/javax/jcr/nodetype/I
>>>> temDefinition.html#isProtected()
>>>> http://www.day.com/specs/jcr/2.0/3_Repository_Model.html#3.7.2.2
>>>> Protected
>>>>
>>>> alex
>>>> ...
>>>
>>> What's the actual node type definition?
>>
>
Re: too many open files / derby / suse
Posted by Thomas Mueller <mu...@adobe.com>.
Hi,
Could you run "lsof" to find out what files are open? I guess most files
are open in a different area (not Derby). If it really is Derby, then an
option is to use another database, for example H2 (disclaimer: I'm one of
the committers of H2).
Regards,
Thomas
On 11/28/11 1:17 PM, "ulf schneider" <us...@datenlabor.net> wrote:
>dear developers,
>i'm running a jackrabbit system with several workspaces (15) and using
>derby as embedded database on suse linux.
>since a few days and after adding another workspace i get exceptions like
>the one that i've attached to this e-mail (reproducable with jackrabbit
>2.2.9 and 2.2.10). i'm suspecting that the failure is originated by the
>number of workspaces.
>ulimit -n prints out a value of 1024.
>
>do you have recommendations how to deal with this issue?
>
>best regards, ulf.
>
>
>2011.11.27 13:11:00.087 ERROR [DbUtility.java:92] failed to close
>Connection
>2011.11.27 13:11:00.087 ERROR [DbUtility.java:94] Reason: Already
>closed.
>2011.11.27 13:11:00.088 ERROR [DbUtility.java:95] State/Code: null/0
>2011.11.27 13:11:00.095 ERROR [ConnectionHelper.java:498] Failed to
>execute SQL (stacktrace on DEBUG log level)
>org.apache.commons.dbcp.SQLNestedException: Borrow prepareStatement from
>pool failed
> at
>org.apache.commons.dbcp.PoolingConnection.prepareStatement(PoolingConnecti
>on.java:98) ~[commons-dbcp-1.2.2.jar:1.2.2]
> at
>org.apache.commons.dbcp.DelegatingConnection.prepareStatement(DelegatingCo
>nnection.java:248) ~[commons-dbcp-1.2.2.jar:1.2.2]
> at
>org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.prepa
>reStatement(PoolingDataSource.java:302) ~[commons-dbcp-1.2.2.jar:1.2.2]
> at
>org.apache.jackrabbit.core.util.db.ConnectionHelper.reallyExec(ConnectionH
>elper.java:387) [jackrabbit-core-2.2.10.jar:2.2.10]
> at
>org.apache.jackrabbit.core.util.db.ConnectionHelper$3.call(ConnectionHelpe
>r.java:371) ~[jackrabbit-core-2.2.10.jar:2.2.10]
> at
>org.apache.jackrabbit.core.util.db.ConnectionHelper$3.call(ConnectionHelpe
>r.java:367) ~[jackrabbit-core-2.2.10.jar:2.2.10]
> at
>org.apache.jackrabbit.core.util.db.ConnectionHelper$RetryManager.doTry(Con
>nectionHelper.java:494) ~[jackrabbit-core-2.2.10.jar:2.2.10]
> at
>org.apache.jackrabbit.core.util.db.ConnectionHelper.exec(ConnectionHelper.
>java:367) [jackrabbit-core-2.2.10.jar:2.2.10]
> at
>org.apache.jackrabbit.core.persistence.pool.BundleDbPersistenceManager.loa
>dReferencesTo(BundleDbPersistenceManager.java:1141)
>[jackrabbit-core-2.2.10.jar:2.2.10]
> at
>org.apache.jackrabbit.core.state.SharedItemStateManager.getNodeReferences(
>SharedItemStateManager.java:335) [jackrabbit-core-2.2.10.jar:2.2.10]
> at
>org.apache.jackrabbit.core.state.LocalItemStateManager.getNodeReferences(L
>ocalItemStateManager.java:218) [jackrabbit-core-2.2.10.jar:2.2.10]
> at
>org.apache.jackrabbit.core.state.XAItemStateManager.getReferences(XAItemSt
>ateManager.java:372) [jackrabbit-core-2.2.10.jar:2.2.10]
> at
>org.apache.jackrabbit.core.state.XAItemStateManager.hasNodeReferences(XAIt
>emStateManager.java:335) [jackrabbit-core-2.2.10.jar:2.2.10]
> at
>org.apache.jackrabbit.core.state.SessionItemStateManager.hasNodeReferences
>(SessionItemStateManager.java:198) [jackrabbit-core-2.2.10.jar:2.2.10]
> at
>org.apache.jackrabbit.core.NodeImpl.getReferences(NodeImpl.java:3028)
>[jackrabbit-core-2.2.10.jar:2.2.10]
> at
>org.apache.jackrabbit.core.NodeImpl.getReferences(NodeImpl.java:2406)
>[jackrabbit-core-2.2.10.jar:2.2.10]
> at
>dlab.content.ocm.OCMStorer.removeTaggingReferences(OCMStorer.java:459)
>[dlab_content_1.4.2.jar:na]
> at dlab.content.ocm.OCMStorer.storeTagging(OCMStorer.java:1064)
>[dlab_content_1.4.2.jar:na]
> at
>dlab.content.ocm.OCMStorer.storeFinalProperty(OCMStorer.java:789)
>[dlab_content_1.4.2.jar:na]
> at
>dlab.content.ocm.ObjectContentMapperJsr170.traverseAndStoreObject(ObjectCo
>ntentMapperJsr170.java:1025) [dlab_content_1.4.2.jar:na]
> at
>dlab.content.ocm.ObjectContentMapperJsr170.traverseAndStoreObject(ObjectCo
>ntentMapperJsr170.java:1066) [dlab_content_1.4.2.jar:na]
> at
>dlab.content.ocm.ObjectContentMapperJsr170.setContent(ObjectContentMapperJ
>sr170.java:698) [dlab_content_1.4.2.jar:na]
> at
>dlab.content.ocm.ObjectContentMapperJsr170.setContent(ObjectContentMapperJ
>sr170.java:710) [dlab_content_1.4.2.jar:na]
> at
>dlab.content.service.ContentService.storeContent(ContentService.java:2908)
> [dlab_content_1.4.2.jar:na]
> at
>dlab.content.service.ContentService.storeContent(ContentService.java:2859)
> [dlab_content_1.4.2.jar:na]
> at
>dlab.docker.document.DocumentEditablePage.store(DocumentEditablePage.java:
>608) [dlab_docker_templating_1.4.2.jar:na]
> at
>dlab.docker.document.DocumentEditablePage.onSubmit(DocumentEditablePage.ja
>va:510) [dlab_docker_templating_1.4.2.jar:na]
> at
>dlab.web.dialog.DialogEditablePage$1.onSubmit(DialogEditablePage.java:116)
> [dlab_web_1.4.2.jar:na]
> at
>org.apache.wicket.markup.html.form.Form$10.component(Form.java:1189)
>[wicket-core-1.5.3.jar:1.5.3]
> at
>org.apache.wicket.markup.html.form.Form$10.component(Form.java:1184)
>[wicket-core-1.5.3.jar:1.5.3]
> at
>org.apache.wicket.util.visit.Visits.visitPostOrderHelper(Visits.java:273)
>[wicket-util-1.5.3.jar:1.5.3]
> at
>org.apache.wicket.util.visit.Visits.visitPostOrder(Visits.java:244)
>[wicket-util-1.5.3.jar:1.5.3]
> at
>org.apache.wicket.markup.html.form.Form.delegateSubmit(Form.java:1182)
>[wicket-core-1.5.3.jar:1.5.3]
> at org.apache.wicket.markup.html.form.Form.process(Form.java:838)
>[wicket-core-1.5.3.jar:1.5.3]
> at
>org.apache.wicket.markup.html.form.Form.onFormSubmitted(Form.java:762)
>[wicket-core-1.5.3.jar:1.5.3]
> at
>org.apache.wicket.markup.html.form.Form.onFormSubmitted(Form.java:692)
>[wicket-core-1.5.3.jar:1.5.3]
> at sun.reflect.GeneratedMethodAccessor175.invoke(Unknown Source)
>~[na:na]
> at
>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorIm
>pl.java:25) ~[na:1.6.0_17]
> at java.lang.reflect.Method.invoke(Method.java:597) ~[na:1.6.0_17]
> at
>org.apache.wicket.RequestListenerInterface.internalInvoke(RequestListenerI
>nterface.java:260) [wicket-core-1.5.3.jar:1.5.3]
> at
>org.apache.wicket.RequestListenerInterface.invoke(RequestListenerInterface
>.java:216) [wicket-core-1.5.3.jar:1.5.3]
> at
>org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.invokeLi
>stener(ListenerInterfaceRequestHandler.java:248)
>[wicket-core-1.5.3.jar:1.5.3]
> at
>org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.respond(
>ListenerInterfaceRequestHandler.java:234) [wicket-core-1.5.3.jar:1.5.3]
> at
>org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(Reque
>stCycle.java:750) [wicket-core-1.5.3.jar:1.5.3]
> at
>org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.
>java:64) [wicket-request-1.5.3.jar:1.5.3]
> at
>org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:252
>) [wicket-core-1.5.3.jar:1.5.3]
> at
>org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.j
>ava:209) [wicket-core-1.5.3.jar:1.5.3]
> at
>org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(Reque
>stCycle.java:280) [wicket-core-1.5.3.jar:1.5.3]
> at
>org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.j
>ava:162) [wicket-core-1.5.3.jar:1.5.3]
> at
>org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:21
>8) [wicket-core-1.5.3.jar:1.5.3]
> at
>org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicati
>onFilterChain.java:235) [catalina-6.0.16.jar:na]
> at
>org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilter
>Chain.java:206) [catalina-6.0.16.jar:na]
> at
>org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.
>java:233) [catalina-6.0.16.jar:na]
> at
>org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.
>java:174) [catalina-6.0.16.jar:na]
> at
>org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:1
>28) [catalina-6.0.16.jar:na]
> at
>org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:1
>02) [catalina-6.0.16.jar:na]
> at
>org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.ja
>va:109) [catalina-6.0.16.jar:na]
> at
>org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286
>) [catalina-6.0.16.jar:na]
> at
>org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
> [tomcat-coyote-6.0.16.jar:na]
> at
>org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Ht
>tp11Protocol.java:583) [tomcat-coyote-6.0.16.jar:na]
> at
>org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
>[tomcat-coyote-6.0.16.jar:na]
> at java.lang.Thread.run(Thread.java:619) [na:1.6.0_17]
>Caused by: java.sql.SQLException: Meta-data for Container
>org.apache.derby.impl.store.raw.data.RAFContainer4@3e6e4eff could not be
>accessed
> at
>org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown
>Source) ~[derby-10.5.3.0_1.jar:na]
> at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown
>Source) ~[derby-10.5.3.0_1.jar:na]
> at org.apache.derby.impl.jdbc.Util.seeNextException(Unknown
>Source) ~[derby-10.5.3.0_1.jar:na]
> at
>org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unkn
>own Source) ~[derby-10.5.3.0_1.jar:na]
> at
>org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown
> Source) ~[derby-10.5.3.0_1.jar:na]
> at
>org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown
>Source) ~[derby-10.5.3.0_1.jar:na]
> at
>org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown
>Source) ~[derby-10.5.3.0_1.jar:na]
> at
>org.apache.derby.impl.jdbc.EmbedPreparedStatement.<init>(Unknown Source)
>~[derby-10.5.3.0_1.jar:na]
> at
>org.apache.derby.impl.jdbc.EmbedPreparedStatement20.<init>(Unknown
>Source) ~[derby-10.5.3.0_1.jar:na]
> at
>org.apache.derby.impl.jdbc.EmbedPreparedStatement30.<init>(Unknown
>Source) ~[derby-10.5.3.0_1.jar:na]
> at
>org.apache.derby.impl.jdbc.EmbedPreparedStatement40.<init>(Unknown
>Source) ~[derby-10.5.3.0_1.jar:na]
> at
>org.apache.derby.jdbc.Driver40.newEmbedPreparedStatement(Unknown Source)
>~[derby-10.5.3.0_1.jar:na]
> at
>org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown
>Source) ~[derby-10.5.3.0_1.jar:na]
> at
>org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown
>Source) ~[derby-10.5.3.0_1.jar:na]
> at
>org.apache.commons.dbcp.PoolingConnection.makeObject(PoolingConnection.jav
>a:193) ~[commons-dbcp-1.2.2.jar:1.2.2]
> at
>org.apache.commons.pool.impl.GenericKeyedObjectPool.borrowObject(GenericKe
>yedObjectPool.java:797) ~[commons-pool-1.3.jar:1.3]
> at
>org.apache.commons.dbcp.PoolingConnection.prepareStatement(PoolingConnecti
>on.java:92) ~[commons-dbcp-1.2.2.jar:1.2.2]
> ... 61 common frames omitted
>Caused by: org.apache.derby.impl.jdbc.EmbedSQLException: Meta-data for
>Container org.apache.derby.impl.store.raw.data.RAFContainer4@3e6e4eff
>could not be accessed
> at
>org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown
>Source) ~[derby-10.5.3.0_1.jar:na]
> at
>org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcros
>sDRDA(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
> ... 78 common frames omitted
>Caused by: org.apache.derby.impl.jdbc.EmbedSQLException: Java exception:
>'/srv/docker/workspaces/CRM/db/seg0/c3f1.dat (Too many open files):
>java.io.FileNotFoundException'.
> at
>org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown
>Source) ~[derby-10.5.3.0_1.jar:na]
> at
>org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcros
>sDRDA(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
> at
>org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown
>Source) ~[derby-10.5.3.0_1.jar:na]
> at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown
>Source) ~[derby-10.5.3.0_1.jar:na]
> at org.apache.derby.impl.jdbc.Util.javaException(Unknown Source)
>~[derby-10.5.3.0_1.jar:na]
> at
>org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unkn
>own Source) ~[derby-10.5.3.0_1.jar:na]
> ... 75 common frames omitted
>Caused by: java.io.FileNotFoundException:
>/srv/docker/workspaces/CRM/db/seg0/c3f1.dat (Too many open files)
> at java.io.RandomAccessFile.open(Native Method) ~[na:1.6.0_17]
> at java.io.RandomAccessFile.<init>(RandomAccessFile.java:212)
>~[na:1.6.0_17]
> at org.apache.derby.impl.io.DirRandomAccessFile.<init>(Unknown
>Source) ~[derby-10.5.3.0_1.jar:na]
> at org.apache.derby.impl.io.DirRandomAccessFile4.<init>(Unknown
>Source) ~[derby-10.5.3.0_1.jar:na]
> at org.apache.derby.impl.io.DirFile4.getRandomAccessFile(Unknown
>Source) ~[derby-10.5.3.0_1.jar:na]
> at org.apache.derby.impl.store.raw.data.RAFContainer.run(Unknown
>Source) ~[derby-10.5.3.0_1.jar:na]
> at java.security.AccessController.doPrivileged(Native Method)
>~[na:1.6.0_17]
> at
>org.apache.derby.impl.store.raw.data.RAFContainer.openContainer(Unknown
>Source) ~[derby-10.5.3.0_1.jar:na]
> at
>org.apache.derby.impl.store.raw.data.RAFContainer4.openContainer(Unknown
>Source) ~[derby-10.5.3.0_1.jar:na]
> at
>org.apache.derby.impl.store.raw.data.FileContainer.setIdent(Unknown
>Source) ~[derby-10.5.3.0_1.jar:na]
> at
>org.apache.derby.impl.store.raw.data.RAFContainer.setIdentity(Unknown
>Source) ~[derby-10.5.3.0_1.jar:na]
> at
>org.apache.derby.impl.services.cache.ConcurrentCache.find(Unknown Source)
>~[derby-10.5.3.0_1.jar:na]
> at
>org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(Unk
>nown Source) ~[derby-10.5.3.0_1.jar:na]
> at
>org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(Unk
>nown Source) ~[derby-10.5.3.0_1.jar:na]
> at
>org.apache.derby.impl.store.raw.xact.Xact.openContainer(Unknown Source)
>~[derby-10.5.3.0_1.jar:na]
> at
>org.apache.derby.impl.store.access.btree.index.B2IFactory.readConglomerate
>(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
> at
>org.apache.derby.impl.store.access.RAMAccessManager.conglomCacheFind(Unkno
>wn Source) ~[derby-10.5.3.0_1.jar:na]
> at
>org.apache.derby.impl.store.access.RAMTransaction.findExistingConglomerate
>(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
> at
>org.apache.derby.impl.store.access.RAMTransaction.openStoreCost(Unknown
>Source) ~[derby-10.5.3.0_1.jar:na]
> at
>org.apache.derby.impl.sql.compile.CompilerContextImpl.getStoreCostControll
>er(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
> at
>org.apache.derby.impl.sql.compile.FromBaseTable.getStoreCostController(Unk
>nown Source) ~[derby-10.5.3.0_1.jar:na]
> at
>org.apache.derby.impl.sql.compile.FromBaseTable.estimateCost(Unknown
>Source) ~[derby-10.5.3.0_1.jar:na]
> at
>org.apache.derby.impl.sql.compile.OptimizerImpl.estimateTotalCost(Unknown
>Source) ~[derby-10.5.3.0_1.jar:na]
> at
>org.apache.derby.impl.sql.compile.OptimizerImpl.costBasedCostOptimizable(U
>nknown Source) ~[derby-10.5.3.0_1.jar:na]
> at
>org.apache.derby.impl.sql.compile.OptimizerImpl.costOptimizable(Unknown
>Source) ~[derby-10.5.3.0_1.jar:na]
> at
>org.apache.derby.impl.sql.compile.FromBaseTable.optimizeIt(Unknown
>Source) ~[derby-10.5.3.0_1.jar:na]
> at
>org.apache.derby.impl.sql.compile.ProjectRestrictNode.optimizeIt(Unknown
>Source) ~[derby-10.5.3.0_1.jar:na]
> at
>org.apache.derby.impl.sql.compile.OptimizerImpl.costPermutation(Unknown
>Source) ~[derby-10.5.3.0_1.jar:na]
> at org.apache.derby.impl.sql.compile.SelectNode.optimize(Unknown
>Source) ~[derby-10.5.3.0_1.jar:na]
> at
>org.apache.derby.impl.sql.compile.DMLStatementNode.optimizeStatement(Unkno
>wn Source) ~[derby-10.5.3.0_1.jar:na]
> at
>org.apache.derby.impl.sql.compile.CursorNode.optimizeStatement(Unknown
>Source) ~[derby-10.5.3.0_1.jar:na]
> at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown
>Source) ~[derby-10.5.3.0_1.jar:na]
> at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown
>Source) ~[derby-10.5.3.0_1.jar:na]
> at
>org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInt
>ernalStatement(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
> ... 71 common frames omitted
>--
>ulf schneider
>+49 163 2505164
>mail: us@datenlabor.net
>blog: http://allesagil.net
>
>datenlabor gmbh
>sitz: paderborn, hrb 8819
>geschäftsführer: ulf schneider
>http://datenlabor.net
>
>Am 25.11.2011 um 18:01 schrieb Julian Reschke:
>
>> On 2011-11-25 17:36, Alex Parvulescu wrote:
>>> ok, I kinda lost here
>>>
>>> any ideas how the root node can be sometimes protected?
>>>
>>>
>>>http://www.day.com/maven/javax.jcr/javadocs/jcr-2.0/javax/jcr/nodetype/I
>>>temDefinition.html#isProtected()
>>> http://www.day.com/specs/jcr/2.0/3_Repository_Model.html#3.7.2.2
>>>Protected
>>>
>>> alex
>>> ...
>>
>> What's the actual node type definition?
>
too many open files / derby / suse
Posted by ulf schneider <us...@datenlabor.net>.
dear developers,
i'm running a jackrabbit system with several workspaces (15) and using derby as embedded database on suse linux.
since a few days and after adding another workspace i get exceptions like the one that i've attached to this e-mail (reproducable with jackrabbit 2.2.9 and 2.2.10). i'm suspecting that the failure is originated by the number of workspaces.
ulimit -n prints out a value of 1024.
do you have recommendations how to deal with this issue?
best regards, ulf.
2011.11.27 13:11:00.087 ERROR [DbUtility.java:92] failed to close Connection
2011.11.27 13:11:00.087 ERROR [DbUtility.java:94] Reason: Already closed.
2011.11.27 13:11:00.088 ERROR [DbUtility.java:95] State/Code: null/0
2011.11.27 13:11:00.095 ERROR [ConnectionHelper.java:498] Failed to execute SQL (stacktrace on DEBUG log level)
org.apache.commons.dbcp.SQLNestedException: Borrow prepareStatement from pool failed
at org.apache.commons.dbcp.PoolingConnection.prepareStatement(PoolingConnection.java:98) ~[commons-dbcp-1.2.2.jar:1.2.2]
at org.apache.commons.dbcp.DelegatingConnection.prepareStatement(DelegatingConnection.java:248) ~[commons-dbcp-1.2.2.jar:1.2.2]
at org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.prepareStatement(PoolingDataSource.java:302) ~[commons-dbcp-1.2.2.jar:1.2.2]
at org.apache.jackrabbit.core.util.db.ConnectionHelper.reallyExec(ConnectionHelper.java:387) [jackrabbit-core-2.2.10.jar:2.2.10]
at org.apache.jackrabbit.core.util.db.ConnectionHelper$3.call(ConnectionHelper.java:371) ~[jackrabbit-core-2.2.10.jar:2.2.10]
at org.apache.jackrabbit.core.util.db.ConnectionHelper$3.call(ConnectionHelper.java:367) ~[jackrabbit-core-2.2.10.jar:2.2.10]
at org.apache.jackrabbit.core.util.db.ConnectionHelper$RetryManager.doTry(ConnectionHelper.java:494) ~[jackrabbit-core-2.2.10.jar:2.2.10]
at org.apache.jackrabbit.core.util.db.ConnectionHelper.exec(ConnectionHelper.java:367) [jackrabbit-core-2.2.10.jar:2.2.10]
at org.apache.jackrabbit.core.persistence.pool.BundleDbPersistenceManager.loadReferencesTo(BundleDbPersistenceManager.java:1141) [jackrabbit-core-2.2.10.jar:2.2.10]
at org.apache.jackrabbit.core.state.SharedItemStateManager.getNodeReferences(SharedItemStateManager.java:335) [jackrabbit-core-2.2.10.jar:2.2.10]
at org.apache.jackrabbit.core.state.LocalItemStateManager.getNodeReferences(LocalItemStateManager.java:218) [jackrabbit-core-2.2.10.jar:2.2.10]
at org.apache.jackrabbit.core.state.XAItemStateManager.getReferences(XAItemStateManager.java:372) [jackrabbit-core-2.2.10.jar:2.2.10]
at org.apache.jackrabbit.core.state.XAItemStateManager.hasNodeReferences(XAItemStateManager.java:335) [jackrabbit-core-2.2.10.jar:2.2.10]
at org.apache.jackrabbit.core.state.SessionItemStateManager.hasNodeReferences(SessionItemStateManager.java:198) [jackrabbit-core-2.2.10.jar:2.2.10]
at org.apache.jackrabbit.core.NodeImpl.getReferences(NodeImpl.java:3028) [jackrabbit-core-2.2.10.jar:2.2.10]
at org.apache.jackrabbit.core.NodeImpl.getReferences(NodeImpl.java:2406) [jackrabbit-core-2.2.10.jar:2.2.10]
at dlab.content.ocm.OCMStorer.removeTaggingReferences(OCMStorer.java:459) [dlab_content_1.4.2.jar:na]
at dlab.content.ocm.OCMStorer.storeTagging(OCMStorer.java:1064) [dlab_content_1.4.2.jar:na]
at dlab.content.ocm.OCMStorer.storeFinalProperty(OCMStorer.java:789) [dlab_content_1.4.2.jar:na]
at dlab.content.ocm.ObjectContentMapperJsr170.traverseAndStoreObject(ObjectContentMapperJsr170.java:1025) [dlab_content_1.4.2.jar:na]
at dlab.content.ocm.ObjectContentMapperJsr170.traverseAndStoreObject(ObjectContentMapperJsr170.java:1066) [dlab_content_1.4.2.jar:na]
at dlab.content.ocm.ObjectContentMapperJsr170.setContent(ObjectContentMapperJsr170.java:698) [dlab_content_1.4.2.jar:na]
at dlab.content.ocm.ObjectContentMapperJsr170.setContent(ObjectContentMapperJsr170.java:710) [dlab_content_1.4.2.jar:na]
at dlab.content.service.ContentService.storeContent(ContentService.java:2908) [dlab_content_1.4.2.jar:na]
at dlab.content.service.ContentService.storeContent(ContentService.java:2859) [dlab_content_1.4.2.jar:na]
at dlab.docker.document.DocumentEditablePage.store(DocumentEditablePage.java:608) [dlab_docker_templating_1.4.2.jar:na]
at dlab.docker.document.DocumentEditablePage.onSubmit(DocumentEditablePage.java:510) [dlab_docker_templating_1.4.2.jar:na]
at dlab.web.dialog.DialogEditablePage$1.onSubmit(DialogEditablePage.java:116) [dlab_web_1.4.2.jar:na]
at org.apache.wicket.markup.html.form.Form$10.component(Form.java:1189) [wicket-core-1.5.3.jar:1.5.3]
at org.apache.wicket.markup.html.form.Form$10.component(Form.java:1184) [wicket-core-1.5.3.jar:1.5.3]
at org.apache.wicket.util.visit.Visits.visitPostOrderHelper(Visits.java:273) [wicket-util-1.5.3.jar:1.5.3]
at org.apache.wicket.util.visit.Visits.visitPostOrder(Visits.java:244) [wicket-util-1.5.3.jar:1.5.3]
at org.apache.wicket.markup.html.form.Form.delegateSubmit(Form.java:1182) [wicket-core-1.5.3.jar:1.5.3]
at org.apache.wicket.markup.html.form.Form.process(Form.java:838) [wicket-core-1.5.3.jar:1.5.3]
at org.apache.wicket.markup.html.form.Form.onFormSubmitted(Form.java:762) [wicket-core-1.5.3.jar:1.5.3]
at org.apache.wicket.markup.html.form.Form.onFormSubmitted(Form.java:692) [wicket-core-1.5.3.jar:1.5.3]
at sun.reflect.GeneratedMethodAccessor175.invoke(Unknown Source) ~[na:na]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) ~[na:1.6.0_17]
at java.lang.reflect.Method.invoke(Method.java:597) ~[na:1.6.0_17]
at org.apache.wicket.RequestListenerInterface.internalInvoke(RequestListenerInterface.java:260) [wicket-core-1.5.3.jar:1.5.3]
at org.apache.wicket.RequestListenerInterface.invoke(RequestListenerInterface.java:216) [wicket-core-1.5.3.jar:1.5.3]
at org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.invokeListener(ListenerInterfaceRequestHandler.java:248) [wicket-core-1.5.3.jar:1.5.3]
at org.apache.wicket.request.handler.ListenerInterfaceRequestHandler.respond(ListenerInterfaceRequestHandler.java:234) [wicket-core-1.5.3.jar:1.5.3]
at org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:750) [wicket-core-1.5.3.jar:1.5.3]
at org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64) [wicket-request-1.5.3.jar:1.5.3]
at org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:252) [wicket-core-1.5.3.jar:1.5.3]
at org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:209) [wicket-core-1.5.3.jar:1.5.3]
at org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:280) [wicket-core-1.5.3.jar:1.5.3]
at org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:162) [wicket-core-1.5.3.jar:1.5.3]
at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:218) [wicket-core-1.5.3.jar:1.5.3]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) [catalina-6.0.16.jar:na]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) [catalina-6.0.16.jar:na]
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) [catalina-6.0.16.jar:na]
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174) [catalina-6.0.16.jar:na]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) [catalina-6.0.16.jar:na]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [catalina-6.0.16.jar:na]
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [catalina-6.0.16.jar:na]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) [catalina-6.0.16.jar:na]
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844) [tomcat-coyote-6.0.16.jar:na]
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) [tomcat-coyote-6.0.16.jar:na]
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) [tomcat-coyote-6.0.16.jar:na]
at java.lang.Thread.run(Thread.java:619) [na:1.6.0_17]
Caused by: java.sql.SQLException: Meta-data for Container org.apache.derby.impl.store.raw.data.RAFContainer4@3e6e4eff could not be accessed
at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
at org.apache.derby.impl.jdbc.Util.seeNextException(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
at org.apache.derby.impl.jdbc.EmbedPreparedStatement.<init>(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.<init>(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.<init>(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
at org.apache.derby.impl.jdbc.EmbedPreparedStatement40.<init>(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
at org.apache.derby.jdbc.Driver40.newEmbedPreparedStatement(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
at org.apache.commons.dbcp.PoolingConnection.makeObject(PoolingConnection.java:193) ~[commons-dbcp-1.2.2.jar:1.2.2]
at org.apache.commons.pool.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:797) ~[commons-pool-1.3.jar:1.3]
at org.apache.commons.dbcp.PoolingConnection.prepareStatement(PoolingConnection.java:92) ~[commons-dbcp-1.2.2.jar:1.2.2]
... 61 common frames omitted
Caused by: org.apache.derby.impl.jdbc.EmbedSQLException: Meta-data for Container org.apache.derby.impl.store.raw.data.RAFContainer4@3e6e4eff could not be accessed
at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
... 78 common frames omitted
Caused by: org.apache.derby.impl.jdbc.EmbedSQLException: Java exception: '/srv/docker/workspaces/CRM/db/seg0/c3f1.dat (Too many open files): java.io.FileNotFoundException'.
at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
at org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
at org.apache.derby.impl.jdbc.Util.javaException(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
... 75 common frames omitted
Caused by: java.io.FileNotFoundException: /srv/docker/workspaces/CRM/db/seg0/c3f1.dat (Too many open files)
at java.io.RandomAccessFile.open(Native Method) ~[na:1.6.0_17]
at java.io.RandomAccessFile.<init>(RandomAccessFile.java:212) ~[na:1.6.0_17]
at org.apache.derby.impl.io.DirRandomAccessFile.<init>(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
at org.apache.derby.impl.io.DirRandomAccessFile4.<init>(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
at org.apache.derby.impl.io.DirFile4.getRandomAccessFile(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
at org.apache.derby.impl.store.raw.data.RAFContainer.run(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
at java.security.AccessController.doPrivileged(Native Method) ~[na:1.6.0_17]
at org.apache.derby.impl.store.raw.data.RAFContainer.openContainer(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
at org.apache.derby.impl.store.raw.data.RAFContainer4.openContainer(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
at org.apache.derby.impl.store.raw.data.FileContainer.setIdent(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
at org.apache.derby.impl.store.raw.data.RAFContainer.setIdentity(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
at org.apache.derby.impl.services.cache.ConcurrentCache.find(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.openContainer(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
at org.apache.derby.impl.store.raw.xact.Xact.openContainer(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
at org.apache.derby.impl.store.access.btree.index.B2IFactory.readConglomerate(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
at org.apache.derby.impl.store.access.RAMAccessManager.conglomCacheFind(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
at org.apache.derby.impl.store.access.RAMTransaction.findExistingConglomerate(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
at org.apache.derby.impl.store.access.RAMTransaction.openStoreCost(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
at org.apache.derby.impl.sql.compile.CompilerContextImpl.getStoreCostController(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
at org.apache.derby.impl.sql.compile.FromBaseTable.getStoreCostController(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
at org.apache.derby.impl.sql.compile.FromBaseTable.estimateCost(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
at org.apache.derby.impl.sql.compile.OptimizerImpl.estimateTotalCost(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
at org.apache.derby.impl.sql.compile.OptimizerImpl.costBasedCostOptimizable(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
at org.apache.derby.impl.sql.compile.OptimizerImpl.costOptimizable(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
at org.apache.derby.impl.sql.compile.FromBaseTable.optimizeIt(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
at org.apache.derby.impl.sql.compile.ProjectRestrictNode.optimizeIt(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
at org.apache.derby.impl.sql.compile.OptimizerImpl.costPermutation(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
at org.apache.derby.impl.sql.compile.SelectNode.optimize(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
at org.apache.derby.impl.sql.compile.DMLStatementNode.optimizeStatement(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
at org.apache.derby.impl.sql.compile.CursorNode.optimizeStatement(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
at org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown Source) ~[derby-10.5.3.0_1.jar:na]
... 71 common frames omitted
--
ulf schneider
+49 163 2505164
mail: us@datenlabor.net
blog: http://allesagil.net
datenlabor gmbh
sitz: paderborn, hrb 8819
geschäftsführer: ulf schneider
http://datenlabor.net
Am 25.11.2011 um 18:01 schrieb Julian Reschke:
> On 2011-11-25 17:36, Alex Parvulescu wrote:
>> ok, I kinda lost here
>>
>> any ideas how the root node can be sometimes protected?
>>
>> http://www.day.com/maven/javax.jcr/javadocs/jcr-2.0/javax/jcr/nodetype/ItemDefinition.html#isProtected()
>> http://www.day.com/specs/jcr/2.0/3_Repository_Model.html#3.7.2.2 Protected
>>
>> alex
>> ...
>
> What's the actual node type definition?
Re: Jackrabbit-trunk - Build # 1755 - Still Unstable
Posted by Julian Reschke <ju...@gmx.de>.
On 2011-11-25 17:36, Alex Parvulescu wrote:
> ok, I kinda lost here
>
> any ideas how the root node can be sometimes protected?
>
> http://www.day.com/maven/javax.jcr/javadocs/jcr-2.0/javax/jcr/nodetype/ItemDefinition.html#isProtected()
> http://www.day.com/specs/jcr/2.0/3_Repository_Model.html#3.7.2.2 Protected
>
> alex
> ...
What's the actual node type definition?
Re: Jackrabbit-trunk - Build # 1755 - Still Unstable
Posted by Alex Parvulescu <al...@gmail.com>.
ok, I kinda lost here
any ideas how the root node can be sometimes protected?
http://www.day.com/maven/javax.jcr/javadocs/jcr-2.0/javax/jcr/nodetype/ItemDefinition.html#isProtected()
http://www.day.com/specs/jcr/2.0/3_Repository_Model.html#3.7.2.2 Protected
alex
On Fri, Nov 25, 2011 at 5:30 PM, Alex Parvulescu
<al...@gmail.com>wrote:
> > Sounds right, though I'm not sure if the importer from JCR-3152 should
> take care of adding that mixin automatically.
>
> Good point, I went into that a bit, and it seems that the importer
> (AccessControlImporter) *may* do that in the #start method (which never
> gets called).
>
> The reason can be found under SessionImporter#startNode:
> if (parent.getDefinition().isProtected())
>
> Here parent is the root node, which seems to fail the test thus makin the
> SessionImporter skip the vital #start call.
> Indeed checking sImpl.getRootNode().getDefinition().isProtected() yields
> false within the test context.
>
> alex
>
> On Fri, Nov 25, 2011 at 4:11 PM, Alex Parvulescu <
> alex.parvulescu@gmail.com> wrote:
>
>> I can't get it to pass anymore:
>>
>> By running
>> rm -rf target; mvn -Dtest=AccessControlImporterTest clean test
>> on jackrabbit-core (a fresh trunk checkout)
>>
>> It fails every time:
>>
>> --------
>> Running org.apache.jackrabbit.core.xml.AccessControlImporterTest
>> Tests run: 13, Failures: 1, Errors: 1, Skipped: 0, Time elapsed: 14.925
>> sec <<< FAILURE!
>>
>> Results :
>>
>> Failed tests:
>> testImportRepoACLAtRoot(org.apache.jackrabbit.core.xml.AccessControlImporterTest):
>> expected:<1> but was:<0>
>>
>> Tests in error:
>>
>> testImportPrincipalBasedACL(org.apache.jackrabbit.core.xml.AccessControlImporterTest):
>> Authorizable for 'administrators' already exists:
>>
>> Tests run: 13, Failures: 1, Errors: 1, Skipped: 0
>> --------
>>
>> It is probably related to running the tests concurrently (JCR-3152
>> mentions that as well).
>>
>> alex
>>
>> On Fri, Nov 25, 2011 at 3:47 PM, Alex Parvulescu <
>> alex.parvulescu@gmail.com> wrote:
>>
>>> Good question, I don't know what are the assumptions about the root node
>>> having some special acl properties.
>>>
>>> I've only seen the last 3 builds fail because of that. It apparently is
>>> a deeper issue. Maybe the proposed fix is not a good idea.
>>>
>>> alex
>>>
>>> On Fri, Nov 25, 2011 at 3:32 PM, Jukka Zitting <ju...@gmail.com>wrote:
>>>
>>>> Hi,
>>>>
>>>> On Fri, Nov 25, 2011 at 2:46 PM, Alex Parvulescu
>>>> <al...@gmail.com> wrote:
>>>> > After studying the neighboring tests, namely inspired by
>>>> > AccessControlImporterTest#testImportRepoACLAtTestNode
>>>> > I think the fix is as simple as adding the missing acl repo info to
>>>> the root
>>>> > node to #testImportRepoACLAtRoot:
>>>> > target.addMixin("rep:RepoAccessControllable");
>>>>
>>>> Sounds right, though I'm not sure if the importer from JCR-3152 should
>>>> take care of adding that mixin automatically.
>>>>
>>>> I encountered the same issue before cutting the 2.3.4 release
>>>> candidate and came to the same conclusion that the
>>>> rep:RepoAccessControllable mixin is not present. Since the problem
>>>> doesn't occur consistently across builds I thought that it was due to
>>>> some test ordering issue. I fixed the test execution order in revision
>>>> 1205866 which seemed to have solved the issue for me, but apparently
>>>> that was just a coincidence.
>>>>
>>>> I wonder if we're still missing something. Why does the test pass
>>>> sometimes without the proposed fix?
>>>>
>>>> BR,
>>>>
>>>> Jukka Zitting
>>>>
>>>
>>>
>>
>
Re: Jackrabbit-trunk - Build # 1755 - Still Unstable
Posted by Alex Parvulescu <al...@gmail.com>.
> Sounds right, though I'm not sure if the importer from JCR-3152 should
take care of adding that mixin automatically.
Good point, I went into that a bit, and it seems that the importer
(AccessControlImporter) *may* do that in the #start method (which never
gets called).
The reason can be found under SessionImporter#startNode:
if (parent.getDefinition().isProtected())
Here parent is the root node, which seems to fail the test thus makin the
SessionImporter skip the vital #start call.
Indeed checking sImpl.getRootNode().getDefinition().isProtected() yields
false within the test context.
alex
On Fri, Nov 25, 2011 at 4:11 PM, Alex Parvulescu
<al...@gmail.com>wrote:
> I can't get it to pass anymore:
>
> By running
> rm -rf target; mvn -Dtest=AccessControlImporterTest clean test
> on jackrabbit-core (a fresh trunk checkout)
>
> It fails every time:
>
> --------
> Running org.apache.jackrabbit.core.xml.AccessControlImporterTest
> Tests run: 13, Failures: 1, Errors: 1, Skipped: 0, Time elapsed: 14.925
> sec <<< FAILURE!
>
> Results :
>
> Failed tests:
> testImportRepoACLAtRoot(org.apache.jackrabbit.core.xml.AccessControlImporterTest):
> expected:<1> but was:<0>
>
> Tests in error:
>
> testImportPrincipalBasedACL(org.apache.jackrabbit.core.xml.AccessControlImporterTest):
> Authorizable for 'administrators' already exists:
>
> Tests run: 13, Failures: 1, Errors: 1, Skipped: 0
> --------
>
> It is probably related to running the tests concurrently (JCR-3152
> mentions that as well).
>
> alex
>
> On Fri, Nov 25, 2011 at 3:47 PM, Alex Parvulescu <
> alex.parvulescu@gmail.com> wrote:
>
>> Good question, I don't know what are the assumptions about the root node
>> having some special acl properties.
>>
>> I've only seen the last 3 builds fail because of that. It apparently is a
>> deeper issue. Maybe the proposed fix is not a good idea.
>>
>> alex
>>
>> On Fri, Nov 25, 2011 at 3:32 PM, Jukka Zitting <ju...@gmail.com>wrote:
>>
>>> Hi,
>>>
>>> On Fri, Nov 25, 2011 at 2:46 PM, Alex Parvulescu
>>> <al...@gmail.com> wrote:
>>> > After studying the neighboring tests, namely inspired by
>>> > AccessControlImporterTest#testImportRepoACLAtTestNode
>>> > I think the fix is as simple as adding the missing acl repo info to
>>> the root
>>> > node to #testImportRepoACLAtRoot:
>>> > target.addMixin("rep:RepoAccessControllable");
>>>
>>> Sounds right, though I'm not sure if the importer from JCR-3152 should
>>> take care of adding that mixin automatically.
>>>
>>> I encountered the same issue before cutting the 2.3.4 release
>>> candidate and came to the same conclusion that the
>>> rep:RepoAccessControllable mixin is not present. Since the problem
>>> doesn't occur consistently across builds I thought that it was due to
>>> some test ordering issue. I fixed the test execution order in revision
>>> 1205866 which seemed to have solved the issue for me, but apparently
>>> that was just a coincidence.
>>>
>>> I wonder if we're still missing something. Why does the test pass
>>> sometimes without the proposed fix?
>>>
>>> BR,
>>>
>>> Jukka Zitting
>>>
>>
>>
>
Re: Jackrabbit-trunk - Build # 1755 - Still Unstable
Posted by Alex Parvulescu <al...@gmail.com>.
I can't get it to pass anymore:
By running
rm -rf target; mvn -Dtest=AccessControlImporterTest clean test
on jackrabbit-core (a fresh trunk checkout)
It fails every time:
--------
Running org.apache.jackrabbit.core.xml.AccessControlImporterTest
Tests run: 13, Failures: 1, Errors: 1, Skipped: 0, Time elapsed: 14.925 sec
<<< FAILURE!
Results :
Failed tests:
testImportRepoACLAtRoot(org.apache.jackrabbit.core.xml.AccessControlImporterTest):
expected:<1> but was:<0>
Tests in error:
testImportPrincipalBasedACL(org.apache.jackrabbit.core.xml.AccessControlImporterTest):
Authorizable for 'administrators' already exists:
Tests run: 13, Failures: 1, Errors: 1, Skipped: 0
--------
It is probably related to running the tests concurrently (JCR-3152 mentions
that as well).
alex
On Fri, Nov 25, 2011 at 3:47 PM, Alex Parvulescu
<al...@gmail.com>wrote:
> Good question, I don't know what are the assumptions about the root node
> having some special acl properties.
>
> I've only seen the last 3 builds fail because of that. It apparently is a
> deeper issue. Maybe the proposed fix is not a good idea.
>
> alex
>
> On Fri, Nov 25, 2011 at 3:32 PM, Jukka Zitting <ju...@gmail.com>wrote:
>
>> Hi,
>>
>> On Fri, Nov 25, 2011 at 2:46 PM, Alex Parvulescu
>> <al...@gmail.com> wrote:
>> > After studying the neighboring tests, namely inspired by
>> > AccessControlImporterTest#testImportRepoACLAtTestNode
>> > I think the fix is as simple as adding the missing acl repo info to the
>> root
>> > node to #testImportRepoACLAtRoot:
>> > target.addMixin("rep:RepoAccessControllable");
>>
>> Sounds right, though I'm not sure if the importer from JCR-3152 should
>> take care of adding that mixin automatically.
>>
>> I encountered the same issue before cutting the 2.3.4 release
>> candidate and came to the same conclusion that the
>> rep:RepoAccessControllable mixin is not present. Since the problem
>> doesn't occur consistently across builds I thought that it was due to
>> some test ordering issue. I fixed the test execution order in revision
>> 1205866 which seemed to have solved the issue for me, but apparently
>> that was just a coincidence.
>>
>> I wonder if we're still missing something. Why does the test pass
>> sometimes without the proposed fix?
>>
>> BR,
>>
>> Jukka Zitting
>>
>
>
Re: Jackrabbit-trunk - Build # 1755 - Still Unstable
Posted by Angela Schreiber <an...@adobe.com>.
hi
any missing ac related mixins are in fact added automatically
when using AccessControllManager#setPolicy. however, the import
of protected items is not triggered if the session importer
does not recognize the protected nature of the item to be imported.
this is determined by the effective node type of that parent
and that's why alex' proposal was correct: the root node must
have the mixin assigned because otherwise the policy node to
be imported is not recognized as such (the defining node type
in that case would be rep:root). should be fixed in rev. 1208362
regards
angela
On 11/25/11 3:47 PM, Alex Parvulescu wrote:
> Good question, I don't know what are the assumptions about the root node
> having some special acl properties.
>
> I've only seen the last 3 builds fail because of that. It apparently is
> a deeper issue. Maybe the proposed fix is not a good idea.
>
> alex
>
> On Fri, Nov 25, 2011 at 3:32 PM, Jukka Zitting <jukka.zitting@gmail.com
> <ma...@gmail.com>> wrote:
>
> Hi,
>
> On Fri, Nov 25, 2011 at 2:46 PM, Alex Parvulescu
> <alex.parvulescu@gmail.com <ma...@gmail.com>> wrote:
> > After studying the neighboring tests, namely inspired by
> > AccessControlImporterTest#testImportRepoACLAtTestNode
> > I think the fix is as simple as adding the missing acl repo info
> to the root
> > node to #testImportRepoACLAtRoot:
> > target.addMixin("rep:RepoAccessControllable");
>
> Sounds right, though I'm not sure if the importer from JCR-3152 should
> take care of adding that mixin automatically.
>
> I encountered the same issue before cutting the 2.3.4 release
> candidate and came to the same conclusion that the
> rep:RepoAccessControllable mixin is not present. Since the problem
> doesn't occur consistently across builds I thought that it was due to
> some test ordering issue. I fixed the test execution order in revision
> 1205866 which seemed to have solved the issue for me, but apparently
> that was just a coincidence.
>
> I wonder if we're still missing something. Why does the test pass
> sometimes without the proposed fix?
>
> BR,
>
> Jukka Zitting
>
>
Re: Jackrabbit-trunk - Build # 1755 - Still Unstable
Posted by Alex Parvulescu <al...@gmail.com>.
Good question, I don't know what are the assumptions about the root node
having some special acl properties.
I've only seen the last 3 builds fail because of that. It apparently is a
deeper issue. Maybe the proposed fix is not a good idea.
alex
On Fri, Nov 25, 2011 at 3:32 PM, Jukka Zitting <ju...@gmail.com>wrote:
> Hi,
>
> On Fri, Nov 25, 2011 at 2:46 PM, Alex Parvulescu
> <al...@gmail.com> wrote:
> > After studying the neighboring tests, namely inspired by
> > AccessControlImporterTest#testImportRepoACLAtTestNode
> > I think the fix is as simple as adding the missing acl repo info to the
> root
> > node to #testImportRepoACLAtRoot:
> > target.addMixin("rep:RepoAccessControllable");
>
> Sounds right, though I'm not sure if the importer from JCR-3152 should
> take care of adding that mixin automatically.
>
> I encountered the same issue before cutting the 2.3.4 release
> candidate and came to the same conclusion that the
> rep:RepoAccessControllable mixin is not present. Since the problem
> doesn't occur consistently across builds I thought that it was due to
> some test ordering issue. I fixed the test execution order in revision
> 1205866 which seemed to have solved the issue for me, but apparently
> that was just a coincidence.
>
> I wonder if we're still missing something. Why does the test pass
> sometimes without the proposed fix?
>
> BR,
>
> Jukka Zitting
>
Re: Jackrabbit-trunk - Build # 1755 - Still Unstable
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Fri, Nov 25, 2011 at 2:46 PM, Alex Parvulescu
<al...@gmail.com> wrote:
> After studying the neighboring tests, namely inspired by
> AccessControlImporterTest#testImportRepoACLAtTestNode
> I think the fix is as simple as adding the missing acl repo info to the root
> node to #testImportRepoACLAtRoot:
> target.addMixin("rep:RepoAccessControllable");
Sounds right, though I'm not sure if the importer from JCR-3152 should
take care of adding that mixin automatically.
I encountered the same issue before cutting the 2.3.4 release
candidate and came to the same conclusion that the
rep:RepoAccessControllable mixin is not present. Since the problem
doesn't occur consistently across builds I thought that it was due to
some test ordering issue. I fixed the test execution order in revision
1205866 which seemed to have solved the issue for me, but apparently
that was just a coincidence.
I wonder if we're still missing something. Why does the test pass
sometimes without the proposed fix?
BR,
Jukka Zitting
Re: Jackrabbit-trunk - Build # 1755 - Still Unstable
Posted by Alex Parvulescu <al...@gmail.com>.
ok, continuing
After studying the neighboring tests, namely inspired by
AccessControlImporterTest#testImportRepoACLAtTestNode
I think the fix is as simple as adding the missing acl repo info to the
root node to #testImportRepoACLAtRoot:
target.addMixin("rep:RepoAccessControllable");
this seems to make the test pass.
any feedback?
alex
On Fri, Nov 25, 2011 at 2:07 PM, Alex Parvulescu
<al...@gmail.com>wrote:
> I debugged the test a bit, maybe it helps in tracking down the problem:
>
> I think the problem is at
>
> ACLEditor#getAclNode line 322
> ACLProvider.isRepoAccessControlled(controlledNode) returns false when I
> think it should return true. controlledNode is the root node
>
> ACLProvider line 385:
> static boolean isRepoAccessControlled(NodeImpl node) throws
> RepositoryException {
> return node.hasNode(N_REPO_POLICY) &&
> node.isNodeType(NT_REP_REPO_ACCESS_CONTROLLABLE);
> }
>
> I guess the root is missing some acl info?
> I may very well be wrong here, so feel free to chime in :)
>
> alex
>
> On Fri, Nov 25, 2011 at 12:20 PM, Apache Jenkins Server <
> jenkins@builds.apache.org> wrote:
>
>> The Apache Jenkins build system has built Jackrabbit-trunk (build #1755)
>>
>> Status: Still Unstable
>>
>> Check console output at
>> https://builds.apache.org/job/Jackrabbit-trunk/1755/ to view the results.
>>
>
>
Re: Jackrabbit-trunk - Build # 1755 - Still Unstable
Posted by Alex Parvulescu <al...@gmail.com>.
I debugged the test a bit, maybe it helps in tracking down the problem:
I think the problem is at
ACLEditor#getAclNode line 322
ACLProvider.isRepoAccessControlled(controlledNode) returns false when I
think it should return true. controlledNode is the root node
ACLProvider line 385:
static boolean isRepoAccessControlled(NodeImpl node) throws
RepositoryException {
return node.hasNode(N_REPO_POLICY) &&
node.isNodeType(NT_REP_REPO_ACCESS_CONTROLLABLE);
}
I guess the root is missing some acl info?
I may very well be wrong here, so feel free to chime in :)
alex
On Fri, Nov 25, 2011 at 12:20 PM, Apache Jenkins Server <
jenkins@builds.apache.org> wrote:
> The Apache Jenkins build system has built Jackrabbit-trunk (build #1755)
>
> Status: Still Unstable
>
> Check console output at
> https://builds.apache.org/job/Jackrabbit-trunk/1755/ to view the results.
>
Jackrabbit-trunk - Build # 1755 - Still Unstable
Posted by Apache Jenkins Server <je...@builds.apache.org>.
The Apache Jenkins build system has built Jackrabbit-trunk (build #1755)
Status: Still Unstable
Check console output at https://builds.apache.org/job/Jackrabbit-trunk/1755/ to view the results.
Re: Jackrabbit-trunk - Build # 1754 - Still Unstable
Posted by Julian Reschke <ju...@gmx.de>.
On 2011-11-25 10:29, Alex Parvulescu wrote:
> can somebody run the build again?
>
> I don't have sufficient rights to do so.
> I'm trying to look at the sql related issues from the latest build
> (#1754) but I keep running into the JCA Resource Adapter test failures
> from the previous build (#1753).
> ...
Just add the JCA Resource Adapter test failure to the exception list in
the pom.xml?
Re: Jackrabbit-trunk - Build # 1754 - Still Unstable
Posted by Alex Parvulescu <al...@gmail.com>.
Good idea Julian, I followed your advice :)
thanks Michael!
alex
On Fri, Nov 25, 2011 at 10:53 AM, Michael Dürig <md...@apache.org> wrote:
>
> Ok just started it.
> Michael
>
>
> On 25.11.11 9:29, Alex Parvulescu wrote:
>
>> can somebody run the build again?
>>
>> I don't have sufficient rights to do so.
>> I'm trying to look at the sql related issues from the latest build
>> (#1754) but I keep running into the JCA Resource Adapter test failures
>> from the previous build (#1753).
>>
>> thanks,
>> alex
>>
>>
>> On Thu, Nov 24, 2011 at 11:52 PM, Apache Jenkins Server
>> <jenkins@builds.apache.org <ma...@builds.apache.org>>>
>> wrote:
>>
>> The Apache Jenkins build system has built Jackrabbit-trunk (build
>> #1754)
>>
>> Status: Still Unstable
>>
>> Check console output at
>> https://builds.apache.org/job/**Jackrabbit-trunk/1754/<https://builds.apache.org/job/Jackrabbit-trunk/1754/>to view the
>> results.
>>
>>
>>
Re: Jackrabbit-trunk - Build # 1754 - Still Unstable
Posted by Michael Dürig <md...@apache.org>.
Ok just started it.
Michael
On 25.11.11 9:29, Alex Parvulescu wrote:
> can somebody run the build again?
>
> I don't have sufficient rights to do so.
> I'm trying to look at the sql related issues from the latest build
> (#1754) but I keep running into the JCA Resource Adapter test failures
> from the previous build (#1753).
>
> thanks,
> alex
>
>
> On Thu, Nov 24, 2011 at 11:52 PM, Apache Jenkins Server
> <jenkins@builds.apache.org <ma...@builds.apache.org>> wrote:
>
> The Apache Jenkins build system has built Jackrabbit-trunk (build #1754)
>
> Status: Still Unstable
>
> Check console output at
> https://builds.apache.org/job/Jackrabbit-trunk/1754/ to view the
> results.
>
>
Re: Jackrabbit-trunk - Build # 1754 - Still Unstable
Posted by Alex Parvulescu <al...@gmail.com>.
can somebody run the build again?
I don't have sufficient rights to do so.
I'm trying to look at the sql related issues from the latest build (#1754)
but I keep running into the JCA Resource Adapter test failures from the
previous build (#1753).
thanks,
alex
On Thu, Nov 24, 2011 at 11:52 PM, Apache Jenkins Server <
jenkins@builds.apache.org> wrote:
> The Apache Jenkins build system has built Jackrabbit-trunk (build #1754)
>
> Status: Still Unstable
>
> Check console output at
> https://builds.apache.org/job/Jackrabbit-trunk/1754/ to view the results.
>