[jira] Created: (JCR-2601) NullPointerException when removing more than one version from history

[Dirk Feufel (JIRA)]

NullPointerException when removing more than one version from history
-

 Key: JCR-2601
 URL: https://issues.apache.org/jira/browse/JCR-2601
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-core
Affects Versions: 2.0.0
Reporter: Dirk Feufel


When removing more than one version from the history, a NullPointerException 
occurres. If I delete the version in the order the VersionIterator provides, I 
get:

at 
org.apache.jackrabbit.core.version.InternalVersionImpl.internalDetach(InternalVersionImpl.java:280)
at 
org.apache.jackrabbit.core.version.InternalVersionHistoryImpl.removeVersion(InternalVersionHistoryImpl.java:389)
at 
org.apache.jackrabbit.core.version.InternalVersionManagerBase.internalRemoveVersion(InternalVersionManagerBase.java:684)
at 
org.apache.jackrabbit.core.version.InternalVersionManagerImpl$5.run(InternalVersionManagerImpl.java:495)
at 
org.apache.jackrabbit.core.version.InternalVersionManagerImpl$DynamicESCFactory.doSourced(InternalVersionManagerImpl.java:760)
at 
org.apache.jackrabbit.core.version.InternalVersionManagerImpl.removeVersion(InternalVersionManagerImpl.java:493)
at 
org.apache.jackrabbit.core.version.InternalXAVersionManager.removeVersion(InternalXAVersionManager.java:264)
at 
org.apache.jackrabbit.core.version.VersionHistoryImpl.removeVersion(VersionHistoryImpl.java:253)

If I delete in the other direction I get:

java.lang.NullPointerException
at 
org.apache.jackrabbit.core.version.InternalVersionImpl.internalDetach(InternalVersionImpl.java:286)
at 
org.apache.jackrabbit.core.version.InternalVersionHistoryImpl.removeVersion(InternalVersionHistoryImpl.java:389)
at 
org.apache.jackrabbit.core.version.InternalVersionManagerBase.internalRemoveVersion(InternalVersionManagerBase.java:684)
at 
org.apache.jackrabbit.core.version.InternalVersionManagerImpl$5.run(InternalVersionManagerImpl.java:495)
at 
org.apache.jackrabbit.core.version.InternalVersionManagerImpl$DynamicESCFactory.doSourced(InternalVersionManagerImpl.java:760)
at 
org.apache.jackrabbit.core.version.InternalVersionManagerImpl.removeVersion(InternalVersionManagerImpl.java:493)
at 
org.apache.jackrabbit.core.version.InternalXAVersionManager.removeVersion(InternalXAVersionManager.java:264)
at 
org.apache.jackrabbit.core.version.VersionHistoryImpl.removeVersion(VersionHistoryImpl.java:253)


The code is:

Node toDelete = session.getNode(path);
VersionHistory vh = 
session.getWorkspace().getVersionManager().getVersionHistory(path);
toRemove.remove();
session.save();
VersionIterator vit = vh.getAllVersions();
while (vit.hasNext()) {
Version v = vit.nextVersion();
if (!v.getName().equals("jcr:rootVersion")) {
versionRemove.add(v.getName());
}
}
for (int i=0; ihttps://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

"flushing" the event queue

[Justin Edelson]

Is there any good way to flush the event queue in Jackrabbit 2? I'm
trying to do this in the context of an integration test. I can get the
effect I want using SynchronousEventListener, but this creates a
Jackrabbit dependency in a place where their shouldn't be one.

Thanks,
Justin

Re: Build failed in Hudson: Jackrabbit-trunk-tests-java14 #435

[Jukka Zitting]

Hi,

On Mon, Apr 12, 2010 at 5:16 PM, Apache Hudson Server
 wrote:
> See 
> 
> [...]
> Building remotely on vesta.apache.org (Ubuntu)
> [...]
> Reason: Cannot find parent: org.apache.jackrabbit:jackrabbit-parent [...]

The main Jackrabbit-trunk build has not yet been run on vesta after
the 2.1 -> 2.2 update, which caused this failure since this separate
jcr-tests build needs the jackrabbit-parent POM to know about the
snapshots on repository.apache.org.

BR,

Jukka Zitting

Build failed in Hudson: Jackrabbit-trunk-tests-java14 #435

[Apache Hudson Server]

See 


--
Started by upstream project "Jackrabbit-trunk" build number 
Building remotely on vesta.apache.org (Ubuntu)
Updating http://svn.apache.org/repos/asf/jackrabbit/trunk/jackrabbit-jcr-tests
At revision 933212
no change for 
http://svn.apache.org/repos/asf/jackrabbit/trunk/jackrabbit-jcr-tests since the 
previous build
[locks-and-latches] Checking to see if we really have the locks
[locks-and-latches] Have all the locks, build can start
[Jackrabbit-trunk-tests-java14] $ /bin/bash -xe 
/tmp/hudson6217489940324574006.sh
+ cd jackrabbit-jcr-tests
+ MAVEN_OPTS=-Xmx128m
+ /home/hudson/tools/maven/apache-maven-2.0.9/bin/mvn clean install
[INFO] Scanning for projects...
[INFO] 
[ERROR] FATAL ERROR
[INFO] 
[INFO] Error building POM (may not be this project's POM).


Project ID: null:jackrabbit-jcr-tests:jar:null

Reason: Cannot find parent: org.apache.jackrabbit:jackrabbit-parent for 
project: null:jackrabbit-jcr-tests:jar:null for project 
null:jackrabbit-jcr-tests:jar:null


[INFO] 
[INFO] Trace
org.apache.maven.reactor.MavenExecutionException: Cannot find parent: 
org.apache.jackrabbit:jackrabbit-parent for project: 
null:jackrabbit-jcr-tests:jar:null for project 
null:jackrabbit-jcr-tests:jar:null
at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:292)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
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:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.project.ProjectBuildingException: Cannot find 
parent: org.apache.jackrabbit:jackrabbit-parent for project: 
null:jackrabbit-jcr-tests:jar:null for project 
null:jackrabbit-jcr-tests:jar:null
at 
org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1370)
at 
org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:821)
at 
org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:506)
at 
org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:198)
at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:583)
at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:461)
at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:365)
... 11 more
Caused by: org.apache.maven.project.ProjectBuildingException: POM 
'org.apache.jackrabbit:jackrabbit-parent' not found in repository: Unable to 
download the artifact from any repository

  org.apache.jackrabbit:jackrabbit-parent:pom:2.2-SNAPSHOT

from the specified remote repositories:
  central (http://repo1.maven.org/maven2)
 for project org.apache.jackrabbit:jackrabbit-parent
at 
org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:603)
at 
org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1366)
... 17 more
Caused by: org.apache.maven.artifact.resolver.ArtifactNotFoundException: Unable 
to download the artifact from any repository

  org.apache.jackrabbit:jackrabbit-parent:pom:2.2-SNAPSHOT

from the specified remote repositories:
  central (http://repo1.maven.org/maven2)

at 
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:212)
at 
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:74)
at 
org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:556)
... 18 more
Caused by: org.apache.maven.wagon.ResourceDoesNotExistException: Unable to 
download the artifact from any repository
at 
org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:331)
at 
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(Defau

RE: Jackrabbit 1.6.0 Write Performance

[george.sibley]

Yes, exactly.

Many thanks. 

-Original Message-
From: Justin Edelson [mailto:justinedel...@gmail.com] 
Sent: 12 April 2010 15:38
To: dev@jackrabbit.apache.org
Subject: Re: Jackrabbit 1.6.0 Write Performance

This looks like https://issues.apache.org/jira/browse/JCR-2579 ?

On 4/12/10 9:25 AM, george.sib...@bt.com wrote:
> Thomas
> 
> We still hit problems when we attempted to add nodes, concurrently, to 
> existing nodes (I think the message was something like "attempting to update 
> a node that is already being updated"). We had to lock the node, update, and 
> then release.  
> 
> Regards
> 
> George
> 
> -Original Message-
> From: Thomas Müller [mailto:thomas.muel...@day.com]
> Sent: 12 April 2010 12:57
> To: dev@jackrabbit.apache.org
> Subject: Re: Jackrabbit 1.6.0 Write Performance
> 
> Hi,
> 
>> With regard to concurrency, are there any plans for jackrabbit to support 
>> concurrency out of the box?
> 
> If you use one session for each thread then it should already work.
> It's a bug if it doesn't.
> 
> In any case I would use one session per thread, no matter if a future version 
> of Jackrabbit supports it or not.
> 
> Regards,
> Thomas

[jira] Updated: (JCR-1242) Improve serialization of NodeReferences for BundleDB PMs

[Arthur Meyer (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-1242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Arthur Meyer updated JCR-1242:
--

Attachment: JCR-1242_update.patch

Attached updated version of the original patch

> Improve serialization of NodeReferences for BundleDB PMs
> 
>
> Key: JCR-1242
> URL: https://issues.apache.org/jira/browse/JCR-1242
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: jackrabbit-core
>Reporter: Przemo Pakulski
>Priority: Minor
> Attachments: JCR-1242-BPM.patch, JCR-1242-ISB.patch, JCR-1242.patch, 
> JCR-1242_update.patch
>
>
> BudleDB PMs use currently Serializer class to serialize, deserialize node 
> references. Those methods are unefficient, it use string representation of 
> UUID, namespaceURI and localName. 
> For UUID rawBytes should be used and for namespaceURI, localName 
> namespaceIndex/nameIndex should be used to improve efficiency of 
> serialization/deserialization.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (JCR-1242) Improve serialization of NodeReferences for BundleDB PMs

[Arthur Meyer (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-1242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12855995#action_12855995
 ] 

Arthur Meyer commented on JCR-1242:
---

Can we update and apply this patch? This patch improves the performance of 
saving nodes with many incoming references significantly.

The compression ratio of the reference representation could be improved even 
further if the reference are grouped by name. 
This way, each name is written only once, which makes the representation of 
references up to 5 times smaller than the current version.


> Improve serialization of NodeReferences for BundleDB PMs
> 
>
> Key: JCR-1242
> URL: https://issues.apache.org/jira/browse/JCR-1242
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: jackrabbit-core
>Reporter: Przemo Pakulski
>Priority: Minor
> Attachments: JCR-1242-BPM.patch, JCR-1242-ISB.patch, JCR-1242.patch
>
>
> BudleDB PMs use currently Serializer class to serialize, deserialize node 
> references. Those methods are unefficient, it use string representation of 
> UUID, namespaceURI and localName. 
> For UUID rawBytes should be used and for namespaceURI, localName 
> namespaceIndex/nameIndex should be used to improve efficiency of 
> serialization/deserialization.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Jackrabbit 1.6.0 Write Performance

[Justin Edelson]

This looks like https://issues.apache.org/jira/browse/JCR-2579 ?

On 4/12/10 9:25 AM, george.sib...@bt.com wrote:
> Thomas
> 
> We still hit problems when we attempted to add nodes, concurrently, to 
> existing nodes (I think the message was something like "attempting to update 
> a node that is already being updated"). We had to lock the node, update, and 
> then release.  
> 
> Regards
> 
> George
> 
> -Original Message-
> From: Thomas Müller [mailto:thomas.muel...@day.com] 
> Sent: 12 April 2010 12:57
> To: dev@jackrabbit.apache.org
> Subject: Re: Jackrabbit 1.6.0 Write Performance
> 
> Hi,
> 
>> With regard to concurrency, are there any plans for jackrabbit to support 
>> concurrency out of the box?
> 
> If you use one session for each thread then it should already work.
> It's a bug if it doesn't.
> 
> In any case I would use one session per thread, no matter if a future version 
> of Jackrabbit supports it or not.
> 
> Regards,
> Thomas

[jira] Resolved: (JCR-2457) Command line access to remote repositories

[Jukka Zitting (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-2457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jukka Zitting resolved JCR-2457.


  Assignee: Jukka Zitting
Resolution: Fixed

The code has been integrated to trunk and the 2.1 branch. There's a number of 
things that could be improved, but since everything basically works I'm 
resolving this as fixed and leaving any additional improvements to followup 
issues.

> Command line access to remote repositories
> --
>
> Key: JCR-2457
> URL: https://issues.apache.org/jira/browse/JCR-2457
> Project: Jackrabbit Content Repository
>  Issue Type: New Feature
>  Components: jackrabbit-standalone
>Reporter: Jukka Zitting
>Assignee: Jukka Zitting
> Fix For: 2.1.0
>
>
> A few years ago Edgar Poce implemented a nice command line JCR access tool 
> called jcr-commands. We haven't really been using it much and the code is 
> currently parked in sandbox/inactive.
> I'd like to resurrect this codebase and integrate it to jackrabbit-standalone 
> to implement command line access to remote repositories. The idea would be to 
> have an easy-to-use tool for simple testing and administration tasks.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

RE: Jackrabbit 1.6.0 Write Performance

[george.sibley]

Thomas

We still hit problems when we attempted to add nodes, concurrently, to existing 
nodes (I think the message was something like "attempting to update a node that 
is already being updated"). We had to lock the node, update, and then release.  

Regards

George

-Original Message-
From: Thomas Müller [mailto:thomas.muel...@day.com] 
Sent: 12 April 2010 12:57
To: dev@jackrabbit.apache.org
Subject: Re: Jackrabbit 1.6.0 Write Performance

Hi,

> With regard to concurrency, are there any plans for jackrabbit to support 
> concurrency out of the box?

If you use one session for each thread then it should already work.
It's a bug if it doesn't.

In any case I would use one session per thread, no matter if a future version 
of Jackrabbit supports it or not.

Regards,
Thomas

[jira] Resolved: (JCR-2600) AbstractLoginModule logs a warning on anonymous logins

[Jukka Zitting (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JCR-2600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jukka Zitting resolved JCR-2600.


Resolution: Fixed

Fixed in revision 933203 and merged to the 2.1 branch in revision 933209.

> AbstractLoginModule logs a warning on anonymous logins
> --
>
> Key: JCR-2600
> URL: https://issues.apache.org/jira/browse/JCR-2600
> Project: Jackrabbit Content Repository
>  Issue Type: Bug
>  Components: jackrabbit-core
>Reporter: Jukka Zitting
>Assignee: Jukka Zitting
>Priority: Trivial
> Fix For: 2.1.0
>
>
> Currently a "No credentials available -> try default (anonymous) 
> authentication" warning is logged by AbstractLoginModule whenever an 
> anonymous login is made. Since this is a normal situation, the log message 
> should be at debug or at most info level.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Jackrabbit 1.6.0 Write Performance

[Thomas Müller]

Hi,

> With regard to concurrency, are there any plans for jackrabbit to support 
> concurrency out of the box?

If you use one session for each thread then it should already work.
It's a bug if it doesn't.

In any case I would use one session per thread, no matter if a future
version of Jackrabbit supports it or not.

Regards,
Thomas

[jira] Created: (JCR-2600) AbstractLoginModule logs a warning on anonymous logins

[Jukka Zitting (JIRA)]

AbstractLoginModule logs a warning on anonymous logins
--

 Key: JCR-2600
 URL: https://issues.apache.org/jira/browse/JCR-2600
 Project: Jackrabbit Content Repository
  Issue Type: Bug
  Components: jackrabbit-core
Reporter: Jukka Zitting
Assignee: Jukka Zitting
Priority: Trivial
 Fix For: 2.1.0


Currently a "No credentials available -> try default (anonymous) 
authentication" warning is logged by AbstractLoginModule whenever an anonymous 
login is made. Since this is a normal situation, the log message should be at 
debug or at most info level.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: AccessManager in Jackrabbit v1.5

[Ivo Kolev]

Hallo, 

I need help on this Jackrabbit AccessManager.
I have custome AccessManager, providing access security based on the logged
account and the permissions an account has. Basically, the permissions apply
over a folder (kind of) - one can see a folder, put some items in it, edit
these items, etc. The type of items a folder can accomodate is also part of
the security.

My problem in particular concerns the creation of item in some folder. In
this case, AccessManager.isGranted(path, perm) is called to resolve the
access. I'm trying to get the new-created item from the session in order to
check its type and if it is applicable to the folder security settings. This
is done through ItemManager and HierarchyManager. The call gets back to
AccessManager.isGranted asking for read permission. Eventually, I'm getting
into a dead loop.

For the other operations I'm using session impersonation with some super
account, having read permission everywhere.

So, does anyone can help with this? I guess I'm not the first fighting this
problem. Thanks.

Cheers, Ivo Kolev
-- 
View this message in context: 
http://n4.nabble.com/AccessManager-in-Jackrabbit-v1-5-tp542582p1836979.html
Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.

RE: Jackrabbit 1.6.0 Write Performance

[george.sibley]

Thomas

Thanks for the update. I'll try both.  

With regard to concurrency, are there any plans for jackrabbit to support 
concurrency out of the box? I did see a thread in the mailing list, but wasn't 
sure of the outcome.

Regards

George

-Original Message-
From: Thomas Müller [mailto:thomas.muel...@day.com] 
Sent: 12 April 2010 08:40
To: dev@jackrabbit.apache.org
Subject: Re: Jackrabbit 1.6.0 Write Performance

Hi,

> - The jackrabbit repository is accessed from our app using RMI.

Can you use the repository in embedded mode? That would help a lot.

> embedded Derby database
> We've tested using postgres

I would test the H2 database if you have time.

Regards,
Thomas

[jira] Commented: (OCM-43) Reviving OCM framework with Jackrabbit 2.x

[Jukka Zitting (JIRA)]

[ 
https://issues.apache.org/jira/browse/OCM-43?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12855881#action_12855881
 ] 

Jukka Zitting commented on OCM-43:
--

Any update on the failing tests?

PS. Quite a large part of the patch is just reformatting the code, which makes 
it difficult to review the exact changes you've made. It looks like the 
reformatting is for the better, so if it's not too much trouble, it would be 
great if you could create a separate patch for just the formatting changes. I 
can commit that without waiting for the unit tests to be fixed.

> Reviving OCM framework with Jackrabbit 2.x
> --
>
> Key: OCM-43
> URL: https://issues.apache.org/jira/browse/OCM-43
> Project: Jackrabbit OCM
>  Issue Type: Improvement
> Environment: Jackrabbit 2.x
>Reporter: Dhrubojyoti Kayal
> Attachments: jar-dependencies.jpg, OCM-43.patch, ocm.patch, ocm.zip, 
> src.zip
>
>   Original Estimate: 168h
>  Remaining Estimate: 168h
>
> The OCM framework currently does not work with Jackrabbit 2.x. This is an 
> excellent framework and allows developers to work with the beans without 
> worrying much about the internal details of working with Nodes and associated 
> Jackrabbit internal classes like session. This is very much in line with ORM 
> and DAO patterns. This allows quick application development and roll out of 
> new entities in the system real easy.
> Tasks required
> + Remove the compilation problems
> + Change/remove the dependencies on old classes and libraries/jars
> + Test
> + Document

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Jackrabbit 1.6.0 Write Performance

[Dhrubo]

George
If you read the documentation you will see RMI is not the recommended mode
of access. Foo whole EJB saga had so much stories about RMI horrors or
whatever.
Best is to use Jackrabbit in embeded mode and expose Remoting layer like
Rest, etc.

On Mon, Apr 12, 2010 at 1:05 PM,  wrote:

>  Hi
>
> We're running a multi-threaded application which creates/updates nodes in
> jackrabbit. Here's an outline of the deployment model:-
>
> - The jackrabbit web app is deployed to the same tomcat instance as our
> main app.
> - The jackrabbit repository is accessed from our app using RMI.
> - We use Threadlocal to confine/isolate the jackrabbit Session.
> - We use jackrabbit node locking to enable concurrency of writes to
> jackrabbit nodes. We have a multiple level node hierarchy where nodes are
> added concurrently.
>
> - We use the embedded Derby database for database persistence.
>
> We're getting a bit of a bottleneck when performing the writes, mainly due
> to the amount of node locking we're having to do. I can't see a way around
> this, so the only measures I can see to improve the performance is speed up
> the writes.
>
> We've tested using postgres for the database persistence, so hopefully we
> should get some performance gains there. Is there anything else that can
> help improve the write performance? E.g. moving back to using the standalone
> server, rather than co-hosting jackrabbit in the same tomcat container as
> the app?
>
> Regards
>
> George Sibley
>
>
>



-- 
Thanks ... Dhrubo
My Book - http://www.apress.com/book/view/1430210095

My Blog -
http://www.jtraining.com/blogs/blogger/dhrubo/

LinkedIn - http://www.linkedin.com/in/dhrubo

Re: Jackrabbit 1.6.0 Write Performance

[Thomas Müller]

Hi,

> - The jackrabbit repository is accessed from our app using RMI.

Can you use the repository in embedded mode? That would help a lot.

> embedded Derby database
> We've tested using postgres

I would test the H2 database if you have time.

Regards,
Thomas

Jackrabbit 1.6.0 Write Performance

[george.sibley]

Hi

We're running a multi-threaded application which creates/updates nodes
in jackrabbit. Here's an outline of the deployment model:-

- The jackrabbit web app is deployed to the same tomcat instance as our
main app.
- The jackrabbit repository is accessed from our app using RMI.
- We use Threadlocal to confine/isolate the jackrabbit Session.
- We use jackrabbit node locking to enable concurrency of writes to
jackrabbit nodes. We have a multiple level node hierarchy where nodes
are added concurrently.
- We use the embedded Derby database for database persistence.

We're getting a bit of a bottleneck when performing the writes, mainly
due to the amount of node locking we're having to do. I can't see a way
around this, so the only measures I can see to improve the performance
is speed up the writes. 

We've tested using postgres for the database persistence, so hopefully
we should get some performance gains there. Is there anything else that
can help improve the write performance? E.g. moving back to using the
standalone server, rather than co-hosting jackrabbit in the same tomcat
container as the app?

Regards


George Sibley

  

[jira] Commented: (JCR-2591) Prevent single-valued property with no value after RTE

[Jukka Zitting (JIRA)]

[ 
https://issues.apache.org/jira/browse/JCR-2591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12855868#action_12855868
 ] 

Jukka Zitting commented on JCR-2591:


Do we have cases where this is needed? AFAIUI none of the relevant code paths 
should be throwing RTEs.

> Prevent single-valued property with no value after RTE
> --
>
> Key: JCR-2591
> URL: https://issues.apache.org/jira/browse/JCR-2591
> Project: Jackrabbit Content Repository
>  Issue Type: Improvement
>  Components: jackrabbit-core
>Affects Versions: 1.6.1
>Reporter: Stephan Huttenhuis
> Attachments: JCR-2591.patch
>
>
> In NodeImpl a newly created property is removed when a checked 
> RepositoryException occurs when setting the value. But if a RuntimeException 
> occurs it is not removed again. It is better to remove it always if settings 
> the value was unsuccessful.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira