Hi,
/jcr:root/content//*[@test='hello']
This XPath query includes the node content.
that's incorrect. /jcr:root/content//* only selects descendants of content,
but not content itself.
there's a XPath test bed you can use here:
hi,
the method Root.getTree(String) does not specify any restrictions for
the passed path string (relative, absolute?). RootImpl then forwards
the call to its rootTree which asserts that the path is absolute. I'd be
good to state this in JavaDoc. on the other hand it seems like the
implementation
: Re: Root.getTree(String)
On 6.9.12 13:50, Michael Dürig wrote:
Hi,¨
On 6.9.12 13:29, Marcel Reutegger wrote:
the method Root.getTree(String) does not specify any restrictions for
the passed path string (relative, absolute?).
This has come up before. See
https
Zitting wrote:
Hi,
On Thu, Sep 6, 2012 at 2:36 PM, Marcel Reutegger
mreut...@adobe.com wrote:
I think we need to throw an exception in this case.
IllegalArgumentException?
This shouldn't be an assertion agreed.
Agreed in general. I've already encountered a few cases where a test
hi all,
while looking through the oak code and also in light of the
recent MongoDB based MicroKernel, I was wondering where
the process boundaries are. right now with the maven build
everything runs in the same process, which is one possible
deployment option. I guess as soon as we have some
hi,
On Mon, Sep 10, 2012 at 12:33 PM, Marcel Reutegger
mreut...@adobe.com wrote:
so, the question I have is basically about oak-core. is it
intended and designed to run in multiple processes and
access a single MicroKernel instance? that way an application
running in multiple processes
Hi,
AFAIU ContentSession.getCurrentRoot() will return the most
up to date version of the root, which provides access to a
snapshot of the tree. In oak-jcr this method is used when
a SessionDelegate is created and the root is initialized with
getCurrentRoot(). Later on this root is used for
hi,
remapping an existing namespace prefix in the namespace registry
somewhat breaks existing content. say we create a node foo:test,
save it and then remap prefix 'foo' to 'bar' in the namespace registry.
reading the same node again will still return foo:bar, however 'foo'
is not valid namespace
How is Jackrabbit handling this?
Jackrabbit always stores names and path values with the namespace uri.
regards
marcel
Hi,
my preference is something like 2), but with the JCR related components
moved to Jackrabbit. I'd like to see Oak as a hierarchical content repository
implementation, but not necessarily as a JCR repository. The plugin mechanism
in Oak was specifically designed for that purpose. Thus
Added:
...
jackrabbit/oak/trunk/oak-
core/src/test/java/org/apache/jackrabbit/oak/TreeTest.java (with props)
Would these fit into TreeImplTest?
I considered that, but then decided against it because TreeImplTest doesn't
have a ContentRepository nor ContentSession. Extending from
Hi,
I think this is the wrong place for the OrderedChildrenEditor. This editor
is required for oak-core to work correctly. It's not an optional or JCR
specific editor.
Regards
Marcel
-Original Message-
From: ju...@apache.org [mailto:ju...@apache.org]
Sent: Freitag, 19. Oktober 2012
OK. If the remaining functionality is something that can't or
shouldn't be removed, then I'd rather see it hardcoded in
Root/TreeImpl than implemented as a plugin.
why can't it be both? It used to be hardcoded in oak-core
before you moved it to RepositoryImpl...
Regards
Marcel
Hi,
I don't think below will work as expected. The PropertyIndexHook now
simply returns the 'unmodified' after state. Instead it should return
the state (from the builder) after it did the modifications. Basically what
the code did in the previous version.
Regards
Marcel
Modified:
Hi,
I noticed that we use ReadOnlyTree in various plugins even though the class
is in the oak core package, which I think should be considered implementation
internal.
I think it makes sense to move it to an spi package. WDYT?
Regards
Marcel
Hi,
I separated the two because I think it's the responsibility of the query
engine to use multiple indexes based on cost when there is more than
one restriction on a filter. This is not implemented right now, but I think
we will have to do that anyway to efficiently execute this query:
hi all,
during the last oak hackathon in basel a couple of people started a
discussion how to implement JCR versioning in oak. I'd like to give
a quick overview what was discussed and how I think we could implement
the various version related operations in oak.
to properly support JCR versioning
Hi,
From: Jukka Zitting [mailto:jukka.zitt...@gmail.com]
On Thu, Nov 29, 2012 at 3:11 PM, Marcel Reutegger
mreut...@adobe.com wrote:
now, to implement the various JCR versioning operations, I'd like
to encapsulate them in commit hooks as much as possible. this
avoid the need to duplicate
Hi,
this is the Apache Oak development list.
You should rather ask your question on the Apache Jackrabbit users list:
us...@jackrabbit.apache.org
Regards
Marcel
-Original Message-
From: AbdulRahman Al-Bacha Hejazi [mailto:a.albacha.hej...@gmail.com]
Sent: Dienstag, 4. Dezember 2012
Hi,
From: Jukka Zitting [mailto:jukka.zitt...@gmail.com]
On Tue, Dec 4, 2012 at 2:02 PM, Marcel Reutegger mreut...@adobe.com
wrote:
this implies that oak-jcr supports non-trivial node type modification. do
we really want to go there? to me this sounds like opening pandorra's
box
From: Jukka Zitting [mailto:jukka.zitt...@gmail.com]
On Wed, Dec 5, 2012 at 9:19 AM, Marcel Reutegger mreut...@adobe.com
wrote:
I guess in the end I can live with either approach, but right now prefer
1). maybe the tie-breaker could be the question how we actually want to
expose
Hi,
From: Jukka Zitting [mailto:jukka.zitt...@gmail.com]
On Wed, Dec 5, 2012 at 12:06 PM, Marcel Reutegger
mreut...@adobe.com wrote:
now, what does that mean for the current oak-core implementation?
to make version operations transactional we need the workspace
Tree and the version
Hi,
To address 1) I suggest we define a set of clear cut cases where any
Microkernel implementations MUST merge. For the other cases I'm not sure
whether we should make them MUST NOT, SHOULD NOT or MAY merge.
I agree and I think three cases are sufficient. MUST, MUST NOT and MAY.
MUST is for
Hi,
I was wondering if the use of headRevisionId in CommitCommandInstructionVisitor
is really correct... isn't it more appropriate to use the base revision of the
associated
commit?
from my POV it makes more sense to apply instructions on stored nodes based on
the base revision instead of the
I guess this makes sense, although I'm curious what MicroKernelIT tests
would fail if we simply change headRevisionId in
CommitCommandInstructionVisitor to baseRevisionId of Commit.
I'll try that out.
I'm thinking
about the case where the passed in revision id is null and also other
cases
times and then sees previous commits or nodes that should be
marked as failed. actually only commits will be marked as failed in MongoMK.
maybe that's the reason why it results in this exception?
regards
marcel
-Original Message-
From: Marcel Reutegger [mailto:mreut...@adobe.com]
Sent
Hi,
doesn't this also change behavior? getStoredNode() was used with both
true and false before. now the nodes are put into the map unconditionally.
doesn’t that mean on copy also the source tree is put into the set of
nodes to commit?
regards
marcel
-Original Message-
From:
Hi,
Mete and I started a discussion about conflicting commits in private
emails and I'd like to move this to the dev list. feel free to jump in
and discuss.
history (most recent first):
hmm, thinking a bit more about this, I think you might be right and committing
against the given base
Hi,
Right, when CommitCommandNew detects a concurrent commit, it retries
the
whole commit loop with mergeNodes etc. but I think the real problem
regarding conflictingMove test is that CommitCommandNew#mergeNodes
does
not detect merge conflicts between base revision nodes and head nodes at
In a nutshell here is what I think we should do: MK.commit should fail
on all but conflicts which are trivially merged. This will not be a
problem for oak-core since oak-core applies changes to private branches
and will merge these on Session.save. Before merging, branches are
rebased and
Instead of the MicroKernel trying to merge changes, I would prefer if the
MicroKernel would fail if a node was changed, moved or deleted after the
base revision of a commit. That way, the MicroKernel API would still need
a base revision in the commit call (the base revision would arguably be
Hi Gardner,
I've been experimenting a bit with Oak and ran into something I thought I
would share, in case there is a worthwhile bug to investigate. I have
com.adobe.granite.quickstart-2012.22-SNAPSHOT.jar, which is rather old
now, but looks to be the latest CRX build that hangs together.
Instead of the MicroKernel trying to merge changes, I would prefer if the
MicroKernel would fail if a node was changed, moved or deleted after the
base revision of a commit. That way, the MicroKernel API would still
need
a base revision in the commit call (the base revision would arguably
Hi,
I see a strange behavior on restart of the repository.
the thread dump shows something like this:
at
org.apache.jackrabbit.oak.kernel.KernelNodeState.getChildNode(KernelNodeState.java:169)
at
org.apache.jackrabbit.oak.spi.state.AbstractNodeState.hasChildNode(AbstractNodeState.java:63)
at
, Jan 16, 2013 at 3:44 PM, Marcel Reutegger
mreut...@adobe.comwrote:
Hi,
I see a strange behavior on restart of the repository.
the thread dump shows something like this:
at
org.apache.jackrabbit.oak.kernel.KernelNodeState.getChildNode(KernelNod
eState.java:169
Please vote on releasing this package as Apache Jackrabbit Oak 0.6.
The vote is open for the next 72 hours and passes if a majority of at
least three +1 Jackrabbit PMC votes are cast.
[X] +1 Release this package as Apache Jackrabbit Oak 0.6
Regards
Marcel
Hmm again... ;-)
[INFO] Step 1. Check release cheksum
[ERROR] Release checksum does not match provided checksum!
I applied Barts fix to the oak release check script. Try again. It works
for me now.
Regards
Marcel
@jackrabbit.apache.org
Subject: [Errored] apache/jackrabbit-oak#496 (trunk - 5072d8d)
Build Update for apache/jackrabbit-oak
-
Build: #496
Status: Errored
Duration: 29 minutes and 56 seconds
Commit: 5072d8d (trunk)
Author: Marcel Reutegger
Message: OAK-588: Run oak
Hi,
+
MongoMK^2 design proposal
+
Segments
The content tree and all its revisions are stored in a collection of
immutable *segments*. Each segment is identified by a UUID and typically
contains a continuous subset of the content
Hi,
no, it's quite different. the equivalent to the journal in Jackrabbit 2.x
is rather the commit collection.
the sync collection contains only a single document, which points to
the head of the commit history. so, it is somewhat similar to the
InstanceRevision we have in Jackrabbit 2.x
Hi,
to elaborate a bit more on this topic. with the current mongomk
implementation the serializing aspect of the sync collection leaks
into the commit collection. that is, even though mongomk allows
two collections to concurrently write nodes and commits, it eventually
has to serialize on the
Hi,
On 05.02.2013, at 11:47, Jukka Zitting
jukka.zitt...@gmail.commailto:jukka.zitt...@gmail.com wrote:
Do you have examples of where the new behavior would be troublesome
for existing code (not just new test cases)? The assumption from the
earlier discussion was that such cases should be
Hi,
On Tue, Feb 26, 2013 at 10:14 AM, Angela Schreiber anch...@adobe.com
wrote:
-1 from my side. i think it's important to distinguish protected
items that are meant to be filled in by the system or by dedicated API.
Agreed, but do we need to make this distinction separately during each
I didn't analyze the results, but could the problem be orderable child
nodes? Currently, oak-core stores a property :childOrder.
no, the problem is how oak-core detects changes between two node
state revisions. for a node with many child nodes in two revisions, oak-core
currently loads all
Hi,
I think it's better to discuss on the mailing list instead of an already
closed issue...
Michael wrote:
It should be possible to combine this with the branch, rebase,
fast forward merge approach I described above : we just need to
make the fast forward merge a bit more clever such that it
Hi,
My take on this was: when we rebase internally anyway, why not make this
rebase available externally so branches could rebase themselves and thus
make it easier for the commit later on? AFAICS the internal rebase would
either have to be on something which pretty much resembles a private
Hi,
I was referring to problem a, which is about validators and other
commit hooks not being a part of the underlying MK-level merge
operation and thus for example not always catching things like
duplicate UUIDs being introduced or hard references being broken (i.e.
repository invariants
On Thu, Mar 7, 2013 at 1:08 PM, Marcel Reutegger mreut...@adobe.com
wrote:
as mentioned before, I think snapshot isolation is just fined because
in most cases it is sufficient and allows for increased concurrency. for
the cases where more consistency guarantees are needed, like
unique
Hi,
When encountering a case where the optimistic locking mechanism can't
push a commit through in say one second, instead of waiting for a
longer while I'd have the SegmentMK fall back to pessimistic locking
where it explicitly acquired a hard lock on the journal and does the
rebase/hook
Hi,
I'd rather avoid casting to an implementation specific class, even if it is
conditional. This may introduce implementation dependent behavior,
which makes debugging more difficult.
If it is for performance reasons, we should look into finding another solution
because the SegmentMK doesn't
right... but i don't see why we have to recalculate the path
when the node states already know about them and we usually
do know the path of an immutable tree because we have
traversed to there using the TreeLocations.
the problem is, only the KernelNodeState knows about its path,
but none of
(trunk - b764e3d)
Build Update for apache/jackrabbit-oak
-
Build: #1078
Status: Broken
Duration: 28 minutes and 21 seconds
Commit: b764e3d (trunk)
Author: Marcel Reutegger
Message: OAK-715: Don't share name space map between SessionImpl
/jackrabbit-oak
-
Build: #1112
Status: Errored
Duration: 5 minutes and 34 seconds
Commit: 2e35050 (trunk)
Author: Marcel Reutegger
Message: OAK-619 Lock-free MongoMK implementation
- more MongoMK.diff() fixes
- Copied over and adapted MongoMKDiffTest from
I'll have a look. Maybe related to one of my recent changes to the MongoMK.
If anyone has a hint how to better reproduce it, please let me know.
Regards
Marcel
-Original Message-
From: Jukka Zitting [mailto:jukka.zitt...@gmail.com]
Sent: Dienstag, 16. April 2013 21:01
To: Oak devs
hi all,
today I encountered a race condition in one of the commit hooks,
which points to a more general problem.
first the specific issue with the PermissionHook. it creates some
nodes if they don't yet exist (/jcr:system/jcr:permissionStore/default)
this happens with the first commit to a
On Thu, Apr 25, 2013 at 1:23 PM, Marcel Reutegger mreut...@adobe.com
wrote:
I'd be interested to hear what people think about this problem.
should we retry commits when these kind of conflicts where
introduced by hooks or editor or do we require the latter to
take care of this and only
:23 PM, Marcel Reutegger wrote:
hi all,
today I encountered a race condition in one of the commit hooks,
which points to a more general problem.
first the specific issue with the PermissionHook. it creates some
nodes if they don't yet exist (/jcr:system/jcr:permissionStore/default
Please vote on releasing this package as Apache Jackrabbit Oak 0.8.
The vote is open for the next 72 hours and passes if a majority of at
least three +1 Jackrabbit PMC votes are cast.
[X] +1 Release this package as Apache Jackrabbit Oak 0.8
All checks OK.
regards
marcel
Hi,
I looked at the PropertyIndexTest first, but the code to setup
the test wasn't straight forward to me. PropertyIndexTest
actually doesn't have a common setup method for its tests.
It was easier for me to copy the initialization code from
MultipleIndicesTest. this also made the actual test
It was easier for me to copy the initialization code from
MultipleIndicesTest. this also made the actual test method
very easy to read and understand.
on second thought, this indicates the new test could go into
MultipleIndicesTest and we avoid the cost of an additional
repo setup.
regards
And with the TarMK:
Added 171000 pages in 36 seconds (0.21ms/page)
Imported 171382 pages in 54 seconds (0.32ms/page)
[...]
Traversed 171382 pages in 2 seconds (0.01ms/page)
I particularly like that last line. :-)
very nice!
regards
marcel
I'm in favor of option 2 and move the MongoMK to oak-core.
we already have the MongoDB backend of the SegmentMK
in oak-core, which means the MongoDB driver dependency
is already there.
Regards
Marcel
-Original Message-
From: Chetan Mehrotra [mailto:chetan.mehro...@gmail.com]
Sent:
hi,
currently most of the oak-jcr tests run on the MicroKernelImpl. to increase
test coverage I'd like to parameterize tests in oak-jcr and run them on the
three major storage flavors we have at the moment: MicroKernelImpl,
SegmentMK and MongoMK.
any objections?
regards
marcel
the reason phrase is a bit misleading. the build failed because
it was still using an old jackrabbit-jcr-tests snapshot version.
should be fine once the fix for JCR-3639 makes its way to
the build machine.
regards
marcel
-Original Message-
From: build...@apache.org
hi all,
our ci builds on travis are failing for quite some time. I just fixed missing
license headers in oak-core, which caused the last build to fail. didn't
we configure travis to always send an email when a build fails?
regards
marcel
was the MaxPermSize change intentional?
regards
marcel
Modified: jackrabbit/oak/trunk/oak-parent/pom.xml
URL: http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-
parent/pom.xml?rev=1513469r1=1513468r2=1513469view=diff
==
never mind, I assume it was unintentional, since the recent travis
build failed for oak-ugrade with a PermSize error.
Jukka increased it to 48m in the past to run oak-ugrade successful.
I'll revert this particual change in a second...
regards
marcel
-Original Message-
From: Marcel
Message-
From: Michael Dürig [mailto:mdue...@apache.org]
Sent: Mittwoch, 14. August 2013 11:15
To: oak-dev@jackrabbit.apache.org
Subject: Re: travis-ci
On 14.8.13 10:46, Marcel Reutegger wrote:
hi all,
our ci builds on travis are failing for quite some time. I just fixed
missing
There indeed was a glitch in the script, triggered by an updated SSL
certificate. Now it should work again.
cool, thanks a lot.
regards
marcel
the new oak-doc/README.md was missing a license header.
fixed in revision 1514194
regards
marcel
-Original Message-
From: Travis CI [mailto:ju...@apache.org]
Sent: Donnerstag, 15. August 2013 10:00
To: oak-dev@jackrabbit.apache.org
Subject: jackrabbit-oak build #1979: Still
my bad, will fix it.
regards
marcel
-Original Message-
From: build...@apache.org [mailto:build...@apache.org]
Sent: Donnerstag, 15. August 2013 10:28
To: oak-dev@jackrabbit.apache.org
Subject: buildbot failure in ASF Buildbot on oak-trunk
The Buildbot has detected a new failure
see http://jackrabbit.apache.org/oak/docs/0.9-SNAPSHOT/participating.html on
how to subscribe to the list.
regards
marcel
-Original Message-
From: Pantula Rajesh [mailto:praj...@adobe.com]
Sent: Montag, 2. September 2013 11:39
To: oak-dev@jackrabbit.apache.org
Subject: Please add
hmm, works for me. maybe related to different JDK version on the build
machine and my machine.
regards
marcel
-Original Message-
From: build...@apache.org [mailto:build...@apache.org]
Sent: Dienstag, 10. September 2013 13:41
To: oak-dev@jackrabbit.apache.org
Subject: buildbot
, Marcel Reutegger wrote:
hmm, works for me. maybe related to different JDK version on the build
machine and my machine.
Looks like http://code.google.com/p/guava-libraries/issues/detail?id=635
Using the TreeMap constructor instead of the static factory method might
work around this problem
Build Update for apache/jackrabbit-oak
-
Build: #2089
Status: Still Failing
Duration: 531 seconds
Commit: 96783708e265263c0e0ca2f12c1527e95a13796a (trunk)
Author: Marcel Reutegger
Message: OAK-926: MongoMK: split documents when they are too large
Hi,
I would turn the log into a debug message, because it can be very confusing.
conflicts happen during regular repository usage and shouldn't log warnings.
if needed one could still enable debug logging to get more information on
what happens during a conflict.
regards
marcel
-Original
@jackrabbit.apache.org; Marcel Reutegger
Subject: Re: svn commit: r1522553 - in /jackrabbit/oak/trunk/oak-core/src:
main/java/org/apache/jackrabbit/oak/plugins/mongomk/
test/java/org/apache/jackrabbit/oak/plugins/mongomk/
hi marcel
could it be that this commit is related to the following test failure?
i
does it only happen with fixture 1? this would rather indicate
it's a MongoMK issue.
regards
marcel
-Original Message-
From: Michael Dürig [mailto:mdue...@apache.org]
Sent: Montag, 16. September 2013 10:21
To: oak-dev@jackrabbit.apache.org
Subject: Re: jackrabbit-oak build #2143:
Please vote on releasing this package as Apache Jackrabbit Oak 0.9.
The vote is open for the next 72 hours and passes if a majority of at
least three +1 Jackrabbit PMC votes are cast.
[X] +1 Release this package as Apache Jackrabbit Oak 0.9
Regards
Marcel
I was getting the same as well, but then deployed the jackrabbit 2.7.1
release locally and retried.
regards
marcel
I am getting
[ERROR] Failed to execute goal on project oak-core: Could not resolve
dependencies for project org.apache.jackrabbit:oak-core:bundle:0.9: The
following
Hi Gavin,
I wasn't aware we have this job on buildbot. we do get notifications
for oak-trunk to our dev list, but not for oak-trunk-win7.
it looks like the builds fail because they run with maven 2.2.1. I think
we require 3.0.x.
Regards
Marcel
-Original Message-
From: Gavin McDonald
Hi,
1) Root#copy
2) Traverse the tree and set new jcr:uuid properties
3) Update references
IMO this fix is not correct and will not work because it's not built
on the nodestate level. The latest root used for the copy will
only see those items accessible to the editing session (i.e.
looks like buildbot ran into the same occasional observation failure
reported earlier by Angela...
the buildbot failure was for MicroKernelImpl (note the [0]), whereas
the failure reported by Angela was for MongoMK ([1]). It looks like this
isn't specific to a single implementation.
regards
Hi,
this quickly results in a root document, which is split very frequently.
the logs will show:
08.10.2013 18:05:21.142 *INFO* [MongoMK background thread]
org.apache.jackrabbit.oak.plugins.mongomk.MongoMK Split operation on 0:/. Size
before: 223382, after: 221378
08.10.2013 18:05:22.155
: a2d3f92f41b5751feb9cfbefc438caf9b2614760 (trunk)
Author: Marcel Reutegger
Message: OAK-1088: Thread safe MongoDocumentStore
- add test, currently ignored
git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1530908
13f79535-47bb-0310-9956-ffa450edef68
View the changeset: https://github.com/apache/jackrabbit
Hi,
You can't. The underlying MicroKernel/NodeStore does not necessarily
store content by hash. In fact neither the MongoMK nor the SegmentMK
do so.
hmm, that's bad. I thought this was one of the fundamental principles that
allow for quick diff/merge and help identify a commit within
we should probably also consider upgrading the java driver. the
default write concern changed with 2.10.0:
http://docs.mongodb.org/manual/release-notes/drivers-write-concern/#driver-write-concern-change
the default is now equivalent to SAFE aka ACKNOWLEDGED.
regards
marcel
-Original
hi,
potentially troublesome due to the extra contention and possible
conflicts on the commitinfo node.
Conflicts at that point cannot occur within a single cluster node since
we are already serialised here.
this may be correct today, but I'm working on the MongoMK to support
concurrent
wrote:
Build Update for apache/jackrabbit-oak
-
Build: #2429
Status: Broken
Duration: 1269 seconds
Commit: 5b0260a4ca87418e0630a816b21b3cdeeb8eec15 (trunk)
Author: Marcel Reutegger
Message: Re-enable MongoDB for tests
git-svn-id:
https
Too many unapproved licenses: 1
deepTree_everyone.xml does not have a license header.
should be fixed now. I added the file to the exlude list.
regards
marcel
-Original Message-
From: Travis CI [mailto:ju...@apache.org]
Sent: Dienstag, 22. Oktober 2013 19:52
To:
Failed tests:
testVersioning(org.apache.jackrabbit.test.api.observation.GetUserDataTest): no
events returned
the test succeeded in the previous build. I created OAK-1107 and will
investigate.
Regards
Marcel
-Original Message-
From: Travis CI [mailto:ju...@apache.org]
Sent:
#2432: Still Failing
Build Update for apache/jackrabbit-oak
-
Build: #2432
Status: Still Failing
Duration: 726 seconds
Commit: 8155fa31413a8076ba4438145aff2092a56db8d1 (trunk)
Author: Marcel Reutegger
Message: OAK-527: benchmark tests
git-svn-id
Hi,
our JCR observation tests are quite slow compared to Jackrabbit.
In an offline discussion with Michael, we suspected the way tests
are written is the culprit. at least the TCK tests may wait up to
five seconds for events. we thought some excluded tests slow
down execution because those do not
i recently discussed this with christian keller and he argued
that this is likely to cause troubles in productive systems.
hmm, but even jackrabbit does not guarantee event delivery
within a certain timeframe.
the main difference is that jackrabbit does a blocking poll and
oak does periodic
Hi,
yesterday Chetan, Thomas and I discussed an access pattern Chetan
saw with the MongoMK. Installing a vlt package shows many reads on
MongoDB for children of nodes that do not have child nodes. these
nodes are the leafs of the tree. due to the current content model,
the MongoMK does not know
The disadvantage is, when a node is added, either:
- then the parent needs to be checked whether is already has this flag set
(if it is in the cache), or
I'd say a parent node is likely in the cache because oak will read it first
before
it is able to add a child.
- the parent needs to be
Hi,
Currently we are storing blobs by breaking them into small chunks and
then storing those chunks in MongoDB as part of blobs collection. This
approach would cause issues as Mongo maintains a global exclusive
write locks on a per database level [1]. So even writing multiple
small chunks of
/jackrabbit-oak
-
Build: #2566
Status: Broken
Duration: 1401 seconds
Commit: 58d87fd16915f133797776ecfaf745f386614ffc (trunk)
Author: Marcel Reutegger
Message: OAK-1080: MongoMK: improved concurrency
- set _lastRev on insert, in all other cases update _lastRev
seconds
Commit: 537e687f9755b3ca1837a3af463e3cfe5f944cd1 (trunk)
Author: Marcel Reutegger
Message: OAK-1149: Avoid exists check in NodeDelegate.getChild() with
empty path
git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1539346
13f79535-47bb-0310-9956-ffa450edef68
View
Please vote on releasing this package as Apache Jackrabbit Oak 0.11.
The vote is open for the next 72 hours and passes if a majority of at
least three +1 Jackrabbit PMC votes are cast.
All checks OK.
+1 Release this package as Apache Jackrabbit Oak 0.11
Regards
Marcel
1 - 100 of 649 matches
Mail list logo
