Created OAK-1294 to track this
Chetan Mehrotra
[1] https://issues.apache.org/jira/browse/OAK-1294
On Wed, Dec 18, 2013 at 3:15 PM, Chetan Mehrotra
wrote:
> The patch works great!!
>
> With patch applied I get similar timings as I got by disabling session
> refresh in LockOperation.
> Chetan Mehr
The patch works great!!
With patch applied I get similar timings as I got by disabling session
refresh in LockOperation.
Chetan Mehrotra
On Wed, Dec 18, 2013 at 2:47 PM, Michael Dürig wrote:
>
>
> On 18.12.13 10:12 , Marcel Reutegger wrote:
>>>
>>> We could rebase the branch and then rebase the
On 18.12.13 10:12 , Marcel Reutegger wrote:
We could rebase the branch and then rebase the in memory changes on top
of the rebased branch. This would get us rid of the branch commit. But
wouldn't get us rid of the rebase operation on the persisted branch. So
I'm not too sure this will gain us a
> We could rebase the branch and then rebase the in memory changes on top
> of the rebased branch. This would get us rid of the branch commit. But
> wouldn't get us rid of the rebase operation on the persisted branch. So
> I'm not too sure this will gain us a lot.
hmm, you are right. this may stil
On 18.12.13 9:20 , Marcel Reutegger wrote:
Hi,
Purging (should) only happen for refresh calls with the keepChanges
parameter set to true. This might be optimised however for the case
where the persisted branch has not yet been created (i.e.
org.apache.jackrabbit.oak.spi.state.AbstractNodeStor
Hi,
> Purging (should) only happen for refresh calls with the keepChanges
> parameter set to true. This might be optimised however for the case
> where the persisted branch has not yet been created (i.e.
> org.apache.jackrabbit.oak.spi.state.AbstractNodeStoreBranch.InMemory) by
> tweaking the way
On 17.12.13 6:26 , Chetan Mehrotra wrote:
6. Session refresh triggers purge of current pending changes leading to a
branch commit
Purging (should) only happen for refresh calls with the keepChanges
parameter set to true. This might be optimised however for the case
where the persisted
Hi,
> On Tue, Dec 17, 2013 at 12:26 PM, Chetan Mehrotra
> wrote:
> > So not sure where the fix is to be done. Should lock check be also
> > restricted to version at which session is pinned or one needs to be at
> > latest revision?
>
> Since the lock checks are normally used to synchronize work
Hi,
On Tue, Dec 17, 2013 at 12:26 PM, Chetan Mehrotra
wrote:
> So not sure where the fix is to be done. Should lock check be also
> restricted to version at which session is pinned or one needs to be at
> latest revision?
Since the lock checks are normally used to synchronize work across
session
Hi,
While profiling slow deployment of some packages on CQ (using Oak)
running on Mongo I noticed that its creating lots of small branch
commits. Looking into the invocation flow following appears to be
happening
1. Package contains lots of small nodes (~7000)
2. DocViewSAXImporter.createNode cre
10 matches
Mail list logo