implements this for MongoDB only. Also the Jira ticket is
Mongo-specific. Is there a plan to implement this for
RDBDocumentStore, too?
ti 14. toukok. 2024 klo 16.36 Stefan Egli (stefane...@apache.org) kirjoitti:
Hi,
We're in the process of merging the Full-GC feature branch into trunk
(via PR [1
Hi,
We're in the process of merging the Full-GC feature branch into trunk
(via PR [1]). Given this is a larger change we'd like to make you aware
of this and encourage reviews.
Since GC is about removing data and given the amount and variety of
garbage we have chosen a defensive approach.
Hi Julian,
Thx for that. That was indeed an unlucky typo from my side..
Cheers,
Stefan
On 30.07.20 10:00, Julian Reschke wrote:
Hi,
please be careful when setting fixVersion in Jira. I just fixed a few
recently resolved tickets where a change in trunk was advertised to fix
1.2.32, not
+1
Cheers,
Stefan
On 27.09.19 11:40, Julian Reschke wrote:
On 04.03.2019 14:29, Davide Giannella wrote:
...
Picking up an old thread...
So we've released 1.12.0, 1.14.0, 1.16.0, and will release 1.18.0 next
week.
What we apparently did not discuss what the project version for trunk
Hi,
I'd like to backport OAK-8351 [0] to the 1.8 and 1.10 branches unless
someone objects. OAK-8351 changes a MongoDB query that was introduced in
this form in 1.8
Cheers,
Stefan
--
[0] https://issues.apache.org/jira/browse/OAK-8351
+1
Cheers,
Stefan
On 20.11.17, 09:24, "Marcel Reutegger" wrote:
>Hi,
>
>I'd like to backport OAK-6953 to the maintenance branches. In some cases,
>it is desirable to disable a cache, which is not possible with the
>current CacheLIRS implementation in Oak. Instead of
Hi Mostafa,
I'd suggest to narrow down why that lease update failed, esp if you have
it reproducible. By default a lease is updated every 10 seconds and is
valid for 2min (and could in theory be changed but that's not recommended
necessarily).
Besides mentioned DB issues, other cases where lease
On 30/05/17 14:51, "Stefan Egli" <stefane...@apache.org> wrote:
>on how Oak could "expose a way to detect the eventual delay".
... "to detect the eventual consistency delay" ...
of course ...
Hi all,
I'd like to invite those interested to join a discussion in
https://issues.apache.org/jira/browse/OAK-6276
on how Oak could "expose a way to detect the eventual delay".
This is a requirement coming from the integration with an external messaging
system in an Oak-based application.
One
Hi,
On 04/05/17 16:56, "Justin Edelson" wrote:
>>Hmm, depending on the Oak version, this may also be caused by OAK-5528.
>> The current fix versions are 1.4.15 and 1.6.0.
>>
>
>Would this show up in thread dumps? Based on the description, it seems
>like
>it should.
Hi Marcel,
IIUC then the sleeps are used to check for expected *and* unexpected
events. The expected part could be easily replaced with a busy-check loop.
The unexpected part is a bit more tricky though, but the test could be
rewritten to be more of a white-box test where not only both ends are
>>
>>But agreed, this is a bug and we should fix it.
>>
>Actually, I'm not too sure as long as we concretely document the
>behavior and potentially have a sample abstract
>commit-creator/listener which does the job well (may be similar to the
>hack I used)
I've created OAK-5740 and attached test
+1, looks like a bug to me.
Cheers,
Stefan
On 09/02/17 23:17, "Vikas Saurabh" wrote:
>Hi,
>
>_Disclaimer_ : I get confused with change processor code, so not sure
>if this is an issue or PEBKAC
>
>ChangeProcessor#queueSizeChanged sets blocking flag to true if queue
On 31/01/17 18:07, "Stefan Egli" <stefane...@apache.org> wrote:
>I'm following up on failure case in oak 1.2.14 where as part of a
>persisted
>branch merge commit hooks do not propagate through all affected changes,
>resulting in an inconsistent state.
>https://is
On 01/02/17 09:16, "Marcel Reutegger" wrote:
>I think in trunk the code path is also a bit different because of
>OAK-4528. It may be possible that the issue still exists in trunk, but
>does not call diffManyChildren() anymore.
>
>What happens when you disable the journal diff
Hi,
I'm following up on failure case in oak 1.2.14 where as part of a persisted
branch merge commit hooks do not propagate through all affected changes,
resulting in an inconsistent state. It's unclear how realistic this scenario
is and/or if it's relevant, but I was able to produce such a
Hi Chetan,
I think the discoverylite and the new 'clustered' property options have
different characteristics. The former describes the current status of the
cluster, irrespective of whether it can be clustered at all. While the
latter is about a capability whether the node store supports
FYI: Assuming lazy consensus I've now committed this one to unblock
1.5.13. We can do post-review in case.
Cheers,
Stefan
On 04/11/16 15:59, "Stefan Egli" <stefane...@apache.org> wrote:
>Hi,
>
>I'd like to commit OAK-4908 which would introduce prefiltering f
as the test coverage is minimal and there's room for code(-style)
improvement.
But the point of this heads-up is about the API of OakEventFilter that
should ideally not have to change anymore, so if you're interested pls
have a look.
Cheers,
Stefan
On 26/10/16 19:09, "Stefan Egli" <stefane.
I've created
https://issues.apache.org/jira/browse/OAK-5039
to follow up
Cheers,
Stefan
On 31/10/16 14:18, "Stefan Egli" <stefane...@apache.org> wrote:
>Hi,
>
>As being discussed in [0] in OAK-5021 there are 2 different ways how
>globbing is currently define
Hi,
As being discussed in [0] in OAK-5021 there are 2 different ways how
globbing is currently defined in Oak vs in Sling. In Oak globbing is
restricted to ** being 0-n path elements and * being 1 path element, while
in Sling it is more generic in that * means 0-n characters excluding path
On 13/09/16 15:27, "Davide Giannella" <dav...@apache.org> wrote:
>On 12/09/2016 09:48, Stefan Egli wrote:
>> IIUC then EventListeners are registered via either JCR's
>> ObservationManager or Jackrabbit's extension at [0]. If you want to do
>> this in Oak
Hi Davide,
On 08/09/16 14:24, "Davide Giannella" wrote:
>On 07/09/2016 14:04, Michael Dürig wrote:
>> No not open them. But make their functionality available through an
>> API. Since JCR is dead (hint hint) we probably have to come up with an
>> ad-hoc API here.
>FWIW, I'm
On 02/09/16 13:41, "Stefan Egli" <stefane...@apache.org> wrote:
>On 02/09/16 13:26, "Chetan Mehrotra" <chetan.mehro...@gmail.com> wrote:
>
>>Listener for local Change
>>--
>>
>>Such a listener is more
Hi Chetan,
(see below)
On 02/09/16 13:26, "Chetan Mehrotra" <chetan.mehro...@gmail.com> wrote:
>On Fri, Sep 2, 2016 at 4:00 PM, Stefan Egli <stefane...@apache.org> wrote:
>> If we
>> separate listeners into purely internal vs external, then a queue as a
Perhaps for backwards compatibility we could auto-create 2 listeners for
the case where a listener is registered without ExcludeInternal or
ExcludeExternal - and issue a corresponding, loud, WARN.
On 02/09/16 12:30, "Stefan Egli" <stefane...@apache.org> wrote:
>Hi,
>
>
Hi,
As an FYI: I'm working on persisting the observation queue - OAK-4581 - and
have attached a patch and a comment [0] to the ticket indicating current
progress. Would welcome some early feedback/review.
The main idea is that it would introduce a 'PersistedBlockingQueue' that
would be plugged
Hi Michael,
On 28/07/16 10:54, "Michael Marth" wrote:
>I think we should simply stick to SemVer of the released artefacts to
>signal those changes to upstream.
IIUC the difference would be that one version (eg oak 1.6) could contain
multiple compatibility versions (eg
;
>On Thu, Jul 28, 2016 at 10:23 AM, Stefan Egli <stefane...@apache.org>
>wrote:
>>...we could introduce a concept of
>> 'compatibility levels' which are a set of features/behaviours that a
>> particular oak version has and that application code relies upon
>
&
(typo)
On 28/07/16 10:23, "Stefan Egli" <stefane...@apache.org> wrote:
>One concrete case where this could have been useful is the
>backwards-compatible behaviour where a session is auto-refreshed when
>changes are done in another session.
.. in the same thread, that is ..
I'd go for #A to limit cross-effects between oak and other layers.
The reason one would want to use the default pool for #4 is probably the
idea that you'd want to avoid "wasting" a thread in the oak-thread-pool
and rather rely on a shared one. But arguably, that should be an
optimization of the
On 22/06/16 12:21, "Chetan Mehrotra" wrote:
>On Tue, Jun 21, 2016 at 4:52 PM, Julian Sedding
>wrote:
>> Not exposing the secondary NodeStore in the service registry would be
>> backwards compatible. Introducing the "type" property potentially
>>
Hi,
On 26/04/16 14:00, "Thomas Mueller" wrote:
>I would keep the "oak-segment-*" name, so that it's clear what it is based
>on. So:
>
>-1 oak-local-store
>-1 oak-embedded-store
>
>+1 oak-segment-*
>
>Within the oak-segment-* options, I don't have a preference.
+1
(I do like
Hi,
On 21/03/16 21:23, "Michael Dürig" wrote:
> There is org.apache.jackrabbit.oak.spi.commit.PartialConflictHandler and
> a couple of its implementations already. Maybe this could be leveraged
> here by somehow connecting it to the mix-ins you propose.
Yes, I think it
On 21/03/16 21:03, "Stefan Egli" <stefane...@apache.org> wrote:
>...a third one could again be 'strict' (which would correspond to JCR
>semantics
>as are the default today) ..
actually that would not be possible asynchronously, scratch that..
Cheers,
Stefan
Hi oak-devs,
tl.dr: suggestion is to introduce a new property (or mixin) that enables
async merge for a subtree in a cluster case while at the same time
pre-defines conflict resolution, since conflicts currently prevent
trouble-free async merging.
In case this has been discussed/suggested
Hi Tomek,
Would also be interesting to see the effect on the leases and thus
discovery-lite under high memory load and network problems.
Cheers,
Stefan
On 04/03/16 11:13, "Tomek Rekawek" wrote:
>Hello,
>
>For some time I've worked on a little project called oak-resilience.
Thanks for the various comments and review on OAK-4006. I've attached a
final version of the patch and will push that later this afternoon
(together with OAK-4007) unless I hear fresh concern.
Cheers,
Stefan
On 11/02/16 20:16, "Stefan Egli" <stefane...@apache.org> wrote:
>Hi
Hi Davide,
As mentioned on the list OAK-4006 is in discussion and in the works. So,
depending on the outcome it might require a small delay.
Cheers,
Stefan
On 11/02/16 11:45, "Davide Giannella" wrote:
>Hello team,
>
>I'm planning to cut Oak 1.3.16 on Monday 15th February
On 11/02/16 20:29, "Vikas Saurabh" wrote:
>we'd really have to shout in the
>documentation that after this, clone use-case requires
>oak-run->reset_id
Agreed. (Side note: but that we'd otherwise have had to do for OAK-3935,
right?)
> (I'm assuming that the approach
Hi all,
The recent clusterId-discussions around OAK-3935 together with the cloning
problem it shares with discovery.oak made me rethink the current
two-clusterId-approach. After some offline discussions with Thomas and
Marcel I've created OAK-4006 which suggests reusing the SharedDataStore way
of
On 11/02/16 20:42, "Vikas Saurabh" wrote:
>probably I mis-understood sling id file as
>cluster id... while I think that's persistent instance id, right?
correct.
Cheers,
Stefan
>
On 10/02/16 14:59, "Davide Giannella" <dav...@apache.org> wrote:
>On 10/02/2016 10:22, Stefan Egli wrote:
>> Re NonLocalObservationIT, that one creates like 160'000 nodes in-memory
>> and that seems not to fit the default VM settings.
>
>Shall we move this to
;
>Regards
> Marcel
>
>On 09/02/16 19:17, "Stefan Egli" wrote:
>
>>Hi,
>>
>>Looks like we need to give our travis run [0] more memory. OAK-3986 was
>>likely partly slowing down due to memory becoming low. Now it looks like
>>ConcurrentAddIT is f
Hi,
Looks like we need to give our travis run [0] more memory. OAK-3986 was
likely partly slowing down due to memory becoming low. Now it looks like
ConcurrentAddIT is failing [1] for the same reason too (can reproduce this
locally: default memory settings result in OOME). I'm guessing adding
not seeing any other negative consequences so
overall d) sounds still better than c).
Unless I hear vetoes, I'd implement this change before tomorrow's 1.3.15
release (also in OAK-3672, which I'll then rename)
Cheers,
Stefan
On 27/01/16 10:45, "Stefan Egli" <stefane...@apache.org
On 14/01/16 18:34, "Julian Reschke" wrote:
>On 2016-01-14 17:36, Vikas Saurabh wrote:
>>@Julian, if I understand correctly, OAK-2682 currently is about
>> warning, right? It mentions a self-desctruct option but I think it
>> wasn't implemented.
>
>It is implemented
- and simplify cleaning this property up for the
clone case (as that would correspond to how this case was dealt with in
discovery.impl times already).
WDYT?
Cheers,
Stefan
On 26/11/15 11:32, "Chetan Mehrotra" <chetan.mehro...@gmail.com> wrote:
>On Thu, Nov 26, 2015 at 3:56 PM, Stefan E
t;
>This would reduce operational complexity
>Chetan Mehrotra
>
>
>On Wed, Nov 25, 2015 at 6:23 PM, Stefan Egli <stefane...@apache.org>
>wrote:
>> Right, I'm not sure it is indeed a requirement. But without automatic
>> support it might get forgotten and thus the clu
Hi,
Noticed that for TarMK the discovery-lite-descriptor does currently not
persist the cluster-view-id [0]. It should do this however, as otherwise
this causes upper-level discovery.oak to break the discovery API, as it
demands a persisted cluster id. (Note that this id is not to be confused
Right, I'm not sure it is indeed a requirement. But without automatic
support it might get forgotten and thus the cluster id would change upon
failover.
Cheers,
Stefan
On 25/11/15 13:40, "Chetan Mehrotra" <chetan.mehro...@gmail.com> wrote:
>On Wed, Nov 25, 2015 at 6:00 PM, S
Hi Carsten,
For external events the commit info is indeed not provided yup.
For internal ones it is - except for those 'overflow' ones which collapse
into a pseudo-external one.
Cheers,
Stefan
On 13/10/15 15:17, "Carsten Ziegeler" wrote:
>Am 17.06.15 um 10:35 schrieb
On 10/09/15 18:43, "Stefan Egli" <stefane...@apache.org> wrote:
>additionally/independently:
>
>[...]
>
>* also, we should probably increase the lease thread's priority to reduce
>the likelihood of the lease timing out (same would be true for
>discove
09-14 10:17, Julian Reschke wrote:
>> On 2015-09-14 10:03, Stefan Egli wrote:
>>> On 14/09/15 09:51, "Marcel Reutegger" <mreut...@adobe.com> wrote:
>>>
>>>> ...would it
>>>> make sense to just disable the lease check for the diagnos
On 14/09/15 09:51, "Marcel Reutegger" wrote:
>...would it
>make sense to just disable the lease check for the diagnostics
>in oak-run? ...
+1 as a short-term fix
Cheers,
Stefan
>clients into thinking they are dealing with a "healthy" instance for
>longer than necessary and thus can lead to bigger issues downstream.
>
>I believe that "fail early and fail often" is the path to a stable
>cluster.
>
>Regards
>Julian
>
>On Th
On 09/09/15 18:11, "Stefan Egli" <stefane...@apache.org> wrote:
>On 09/09/15 18:01, "Stefan Egli" <stefane...@apache.org> wrote:
>
>>I think if the observers would all be 'OSGi-ified' then this could be
>>achieved. But currently eg the BackgroundO
.
What do ppl think?
Cheers,
Stefan
--
[0] https://issues.apache.org/jira/browse/OAK-3250
[1] https://issues.apache.org/jira/browse/OAK-3373
On 18/08/15 16:45, "Stefan Egli" <e...@adobe.com> wrote:
>I've created OAK-3250 to follow up on the DocumentNodeStore-restart idea.
Hi,
On 09/09/15 17:39, "Marcel Reutegger" wrote:
>>* as pointed out by MichaelD they could have a backlog yet to process
>>towards the old store - which they cannot access anymore as that one
>>would
>>be forcibly closed
>
>in my view, those observers should be unregistered
On 09/09/15 18:01, "Stefan Egli" <stefane...@apache.org> wrote:
>I think if the observers would all be 'OSGi-ified' then this could be
>achieved. But currently eg the BackgroundObserver is just a pojo and not
>an osgi component (thus doesn't support any activate/deactiv
anymore
Cheers,
Stefan
--
[0]
http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-core/src/test/java/or
g/apache/jackrabbit/oak/plugins/document/VersionGarbageCollectorIT.java?r1=
1700741=1700740=1700741
On 07/09/15 10:25, "Michael Dürig" <mdue...@apache.org> wrote:
>
>
>
'... System.exit called ...'
what we currently have until OAK-3250 is fixed is a System.exit when the
lease cannot be updated.
so perhaps it's a lease timeout case..
Cheers,
Stefan
On 31/08/15 16:00, "Michael Dürig" wrote:
>
>"The forked VM terminated without saying
which you might have noticed since I disabled redirectTestOutputToFile [0]
to debug OAK-3292 so we now have system.out during test runs. I intend to
put that flag back once the OAK-3292 dust has settled..
Cheers,
Stefan
--
[0] - http://svn.apache.org/r1697676
On 27/08/15 13:51, Alex Parvulescu
yep, very useful, thx!
Cheers,
Stefan
On 26/08/15 11:47, Michael Dürig mdue...@apache.org wrote:
Hi,
As you might have seen, Jenkins notifications now contain the change
list since the last build as well as the list of failed tests. This
should make it easier for everyone to find out what
Hi,
I'm chasing a test failure on travis ([0]) currently but it's virtually
impossible to find the root cause without having the console (or file)
output of the test in case it fails.
Does anyone know if/how to get the surefire files on travis? or should we
tweak the pom
On 18/08/15 13:43, Marcel Reutegger mreut...@adobe.com wrote:
On 18/08/15 11:14, Stefan Egli wrote:
b) Oak does not do the System.exit but refuses to update anything towards
the document store (thus just throws exceptions on each invocation) - and
upper level code detects this situation (eg
I've created OAK-3250 to follow up on the DocumentNodeStore-restart idea.
Cheers,
Stefan
--
https://issues.apache.org/jira/browse/OAK-3250
On 18/08/15 15:59, Marcel Reutegger mreut...@adobe.com wrote:
On 18/08/15 15:38, Stefan Egli wrote:
On 18/08/15 13:43, Marcel Reutegger mreut...@adobe.com
my fault, I¹m looking into it now
On 17/08/15 12:02, Davide Giannella dav...@apache.org wrote:
Hello team,
trying to release Oak 1.3.4 but it's constantly failing on my local.
Details can be found here
https://issues.apache.org/jira/secure/attachment/12750782/oak-1.3.4-failin
g-1439805620.log
/OAK-2844.v4.patch
On 07/07/15 12:45, Stefan Egli stefane...@apache.org wrote:
FYI: I've attached a suggested 'final draft' version of the discovery lite
to OAK-2844 for review. Comments very welcome!
Cheers,
Stefan
--
https://issues.apache.org/jira/browse/OAK-2844?focusedCommentId=14616496p
a
ge
Hi all,
Just a quick heads-up: I¹ve activated a lease check¹ with OAK-2739 in
trunk: this checks upon every invocation of DocumentStore if the local lease
is still valid. If it is not, it means that the instance is misbehaving and
that others potentially have seen it as inactive. Thus the local
I¹d find it more useful (for us) when it would be the cut-date.
Cheers,
Stefan
On 13/08/15 10:08, Davide Giannella dav...@apache.org wrote:
Hello team,
a trivia question about release dates.
Normally in jira I set the release date on a future release for when we
plan to cut it. But we have
, i would suggest you assign the
issue to yourself in order to keep track of it (compared to the
whole bunch of other unscheduled issues). or flag it with a
label that allows you to find all your wishes.
so, rather -1 from my side.
kind regards
angela
On 29/07/15 08:58, Stefan Egli stefane
+1
There's always the jira history to figure out when what was modified
Cheers,
Stefan
On 7/29/15 8:17 AM, Chetan Mehrotra chetan.mehro...@gmail.com wrote:
Hi Team,
Currently most of the issues scheduled for 1.3.x release have comments
like 'Bulk Move to xxx'. This creates unnecessary noise
-14616496
On 5/6/15 3:22 PM, Stefan Egli stefane...@apache.org wrote:
Hi,
Pls note a suggestion of a new 'discovery-light' API in OAK-2844.
Would appreciate comments and reviews from this list.
Thanks,
Cheers,
Stefan
+1 to report and continue.
There was a similar issue earlier where the async indexing would fail with
an OOME - in which case the 'rinse and repeat' even made it worse (as each
time more and more data-to-be-indexed accumulates and the likelihood of an
OOME would just increase)
Cheers,
Stefan
On
issue closely
related to your request:
https://issues.apache.org/jira/browse/OAK-2066
I think in general it makes sense to add such a method. As
you can see in the issue, the background write is not the only
application that would benefit from it.
Regards
Marcel
On 18/06/15 17:24, Stefan Egli
Hi,
This might have been discussed before but just so I understand:
The DocumentNodeStore.backgroundWrite goes through the heavy work of
updating the lastRev for all pending changes and does so in a
hierarchical-depth-first manner. Unfortunately, if the pending changes all
come from separate
On 6/15/15 2:40 PM, Carsten Ziegeler cziege...@apache.org wrote:
Am 15.06.15 um 14:23 schrieb Marcel Reutegger:
Hi,
you can write a CommitEditor, which is called with every
local commit.
Is it easy to calculate the changed nodes/properties in this editor?
As I understand yes, the Editor
On 6/15/15 4:29 PM, Carsten Ziegeler cziege...@apache.org wrote:
Am 15.06.15 um 16:21 schrieb Chetan Mehrotra:
On Mon, Jun 15, 2015 at 1:13 PM, Carsten Ziegeler
cziege...@apache.org wrote:
Now, with Oak there is still this distinction, however if I remember
correctly under heavy load it might
Hi,
Just realized that DocumentNodeStore background read and update operations
are synchronized which basically makes them be executed sequentially
which somewhat works against OAK-2624.
@Marcel, @Chetan, wdyt, do they have to be synchronized? Could this not be a
bottleneck concurrency-wise?
Hi,
Pls note a suggestion of a new 'discovery-light' API in OAK-2844.
Would appreciate comments and reviews from this list.
Thanks,
Cheers,
Stefan
makes
sense
to have bigger queues for such listners
Chetan Mehrotra
On Mon, Mar 23, 2015 at 4:09 PM, Michael Dürig mdue...@apache.org wrote:
On 23.3.15 11:03 , Stefan Egli wrote:
Going one step further we could also discuss to completely moving the
handling of the 'observation queues
Going one step further we could also discuss to completely moving the
handling of the 'observation queues' to an actual messaging system.
Whether this would be embedded to an oak instance or whether it would be
shared between instances in an oak cluster might be a different question
(the embedded
:13 PM, Alex Parvulescu alex.parvule...@gmail.com wrote:
Hi Stefan,
Offline compaction should work properly.
Can you quickly check the number of checkpoints?
alex
On Mon, Jan 26, 2015 at 6:12 PM, Stefan Egli stefane...@apache.org
wrote:
Hi,
Before I dig too deep I built the latest trunk
It looks like no compaction strategy is set in oak-run.
Created https://issues.apache.org/jira/browse/OAK-2449
Cheers,
Stefan
On 1/27/15 9:58 AM, Stefan Egli e...@adobe.com wrote:
Hi Alex,
There's only 1 checkpoint, so that looks good. I still see the same..
oak-run 1.0.8 compacts fine
Hi,
Before I dig too deep I built the latest trunk and tried to run offline
compaction but see a weird behavior where oak-run starts filling one tar
file after the other basically increasing seemingly endlessly.
Is this known or only me?
Cheers,
Stefan
Hi,
On 4/16/13 4:26 PM, Dominik Süß dominik.su...@gmail.com wrote:
I see some overlap with the latest work of Carsten in Sling regarding
Discovery API[0]. Since Sling typically should work uppon JCR / Oak it
might be good not to follow different patterns. For a combined solution I
do think it
87 matches
Mail list logo