Hi,
I am not the member of the OAK team, but I can share my experiences with
you. When we were deciding about infrastructure I did some load tests,
and IMO relational database isn't the best choice for OAK. For small
number of documents it's ok, but after exceeding a certain number, index
on table with nodes was the bottleneck. Mongodb doesn't have such
problems. It took me some time to convince team to use mongo but it was
worth it, during tests "nodes" collection had over 200millions items and
everything worked fine. Not sure if you have the same problem, but check
database load.
Second thing, if you start repository manually, f.e. on application
server, be sure to execute all necessary services, like garbage
collectors and sweep. Without that you will have a lot of garbage
slowing down your system.
Another important thing to do when working on application server is to
set ExecutorService, by default everything is working on one thread if I
remember well. On wildfly I have defined managed executor service with
thread pool for OAK.
I hope some of that will help you.
Best regards,
Piotr
P.S.
Here are some methods from my RepositoryService which I call from EJB
timers:
public void gcVersion() {
if(documentNodeStore!=null) {
if(documentNodeStore.getVersionGarbageCollector()!=null) {
try {
documentNodeStore.getVersionGarbageCollector().gc(3600, TimeUnit.SECONDS);
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}
}
public void gcJournal() {
if(documentNodeStore!=null) {
if(documentNodeStore.getJournalGarbageCollector()!=null) {
documentNodeStore.getJournalGarbageCollector().gc();
}
}
}
public void gcBlob() {
if(blobGC!=null) {
try {
blobGC.collectGarbage(false);
} catch (Exception e) {
e.printStackTrace();
}
}
}
public void sweep() {
if(documentNodeStore!=null) {
if(documentNodeStore.getLastRevRecoveryAgent()!=null) {
documentNodeStore.getLastRevRecoveryAgent().performRecoveryIfNeeded();
}
}
}
On 16.12.2019 10:26, Tanvi Shah wrote:
Hi,
We are implementing versioning of jcr:content with repository having more than
100,000 of nodes. But after adding the mixin for mix:versionable the session is
taking too much time for saving the data.
We are using Postgres as the database and are using 1.10.2 version of
Jackrabbit oak.
Versioning takes more than 4 minutes of time to save the session on the larger
repository.
Till now we didn't use any versioning for the nodes and this is working fine in
the lower environment with lesser number of nodes in repository.
The code is :
final Node content = file.addNode(Property.JCR_CONTENT, NodeType.NT_RESOURCE);
content.addMixin(NodeType.MIX_VERSIONABLE);
content.setProperty(Property.JCR_DATA, binary);
session.save();
log.info("Saving session and chekin the node");
versionManager.checkin(content.getPath());
So please help me with solving this problem where session takes minimum time
for saving as this has become a blocker for us. Thank you in advance.
Regards,
Tanvi Shah
This e-mail is confidential and should not be used by anyone who is not the
original intended recipient. If you have received this e-mail in error please
inform the sender and delete it from your mailbox or any other storage
mechanism. Springer Nature Technology and Publishing Solutions Private Limited
does not accept liability for any statements made which are clearly the
sender's own and not expressly made on behalf of Springer Nature Technology and
Publishing Solutions Private Limited or one of their agents.
Please note that Springer Nature Technology and Publishing Solutions Private
Limited and their agents and affiliates do not accept any responsibility for
viruses or malware that may be contained in this e-mail or its attachments and
it is your responsibility to scan the e-mail and attachments (if any).
Springer Nature Technology and Publishing Solutions Private Limited. Registered
office: Upper Ground Floor, Wing B, Tower 8, Magarpatta City SEZ, Hadapsar Pune
MH 411013 IN
Registered number: U72200PN2006FTC128967
