Re: Scalability of JCR observation

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

[segment] offline compaction broken?

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

Re: [segment] offline compaction broken?

: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

Re: [segment] offline compaction broken?

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

Re: Efficiently process observation event for local changes

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

Re: Efficiently process observation event for local changes

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

[discovery] Introducing a simple mongo-based discovery-light service (to circumvent mongoMk's eventual consistency delays)

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

DocumentNodeStore background read/update operations synchronized?

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?

[mongoNs] using bulk operation for backgroundupdate?

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

Re: Error handling during AsyncIndexUpdate

+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

Re: [mongoNs] using bulk operation for backgroundupdate?

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

Re: Observation: External vs local - Load distribution

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

Re: Observation: External vs local - Load distribution

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

Re: Release dates

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

Re: 1.3.4 blocked as failing tests

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

Re: [discovery] Introducing a simple mongo-based discovery-light service (to circumvent mongoMk's eventual consistency delays)

/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

Re: System.exit()???? , was: svn commit: r1696202 - in /jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document: ClusterNodeInfo.java DocumentMK.java DocumentNodeStore.j

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

Re: System.exit()???? , was: svn commit: r1696202 - in /jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document: ClusterNodeInfo.java DocumentMK.java DocumentNodeStore.j

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

[document] lease check activated (OAK-2739)

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

Re: [discuss] handling of 'wish list' issues - introduce 'wish list' fix version?

, 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

Re: Do not add comments when bulk moves are performed in JIRA

+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

Re: Observation: External vs local - Load distribution

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

Re: [discovery] Introducing a simple mongo-based discovery-light service (to circumvent mongoMk's eventual consistency delays)

-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

Re: System.out.println used in unit tests in oak-core

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

Re: Jenkins notifications

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

[travis] console output of failed tests

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

Re: [Oak origin/trunk] Apache Jackrabbit Oak matrix - Build # 381 - Failure

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: > > >

Re: [Oak origin/trunk] Apache Jackrabbit Oak matrix - Build # 381 - Failure

'... 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

Re: System.exit()???? , was: svn commit: r1696202 - in /jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document: ClusterNodeInfo.java DocumentMK.java DocumentNodeStore.j

. 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.

Re: System.exit()???? , was: svn commit: r1696202 - in /jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document: ClusterNodeInfo.java DocumentMK.java DocumentNodeStore.j

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

Re: System.exit()???? , was: svn commit: r1696202 - in /jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document: ClusterNodeInfo.java DocumentMK.java DocumentNodeStore.j

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

Re: System.exit()???? , was: svn commit: r1696202 - in /jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document: ClusterNodeInfo.java DocumentMK.java DocumentNodeStore.j

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

Re: System.exit()???? , was: svn commit: r1696202 - in /jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document: ClusterNodeInfo.java DocumentMK.java DocumentNodeStore.j

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

Re: Oak 1.3.6 release plan

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

Re: Oak 1.3.6 release plan

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

Re: System.exit()???? , was: svn commit: r1696202 - in /jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document: ClusterNodeInfo.java DocumentMK.java DocumentNodeStore.j

>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

[discuss] persisting cluster (view) id for discovery-lite-descriptor

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

Re: [discuss] persisting cluster (view) id for discovery-lite-descriptor

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

Re: [discuss] persisting cluster (view) id for discovery-lite-descriptor

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

Re: Requirement to support multiple NodeStore instance in same setup (OAK-4490)

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 >>

Re: travis needs more memory

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

Re: Oak 1.3.16 release plan

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

travis needs more memory

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

Re: travis needs more memory

; >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

Re: OAK-4006 : Enable cloning of repo for shared data store and discovery-lite

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

OAK-4006 : Enable cloning of repo for shared data store and discovery-lite

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

Re: OAK-4006 : Enable cloning of repo for shared data store and discovery-lite

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 >

Re: [DISCUSS] avoid bad commits with mis-behaving clock

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

Re: [discuss] persisting cluster (view) id for discovery-lite-descriptor

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

Re: [discuss] persisting cluster (view) id for discovery-lite-descriptor

- 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

Re: OAK-4006 : Enable cloning of repo for shared data store and discovery-lite

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

Re: [discuss][scalability] oak:asyncConflictResolution

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

[discuss][scalability] oak:asyncConflictResolution

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

Re: [discuss][scalability] oak:asyncConflictResolution

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

Re: oak-resilience

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.

Re: [VOTE] Please vote for the final name of oak-segment-next

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

Re: [suggestion] introduce oak compatibility levels

(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 ..

Re: Requirements for multiple Oak clients on the same backend (was: [suggestion] introduce oak compatibility levels)

; >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 > &

Re: [suggestion] introduce oak compatibility levels

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

Re: Specifying threadpool name for periodic scheduled jobs (OAK-4563)

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

Re: incomplete diffManyChildren during a persisted branch merge

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

incomplete diffManyChildren during a persisted branch merge

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

Re: incomplete diffManyChildren during a persisted branch merge

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

Re: [Observation] Should listeners require constant inflow of commits to get all events?

>> >>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

Re: ChangeProcessor potentially warns only once for queue being full during its lifetime (without CommitRateLimiter)

+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

Re: [observation] pure internal or external listeners

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

Re: [observation] pure internal or external listeners

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

Re: [observation] pure internal or external listeners

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, > >

[wip][review] persistent observation queue - OAK-4581

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

Re: [observation] more options in JackrabbitEventFilter

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

Re: [observation] more options in JackrabbitEventFilter

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

Re: [REVIEW] OAK-4908 in 1.5.13: prefiltering (enabled by default)

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

Re: Detecting if setup is a cluster or a single node via repository Descriptors

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

globbing: oak style vs sling style

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

Re: globbing: oak style vs sling style

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

Re: [REVIEW][API] Additions to JackrabbitEventFilter

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.

Re: single node cluster

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

Re: ObservationTest with Thread.sleep()

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

Re: [discuss] expose way to detect "eventual consistency delay"

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 ...

[discuss] expose way to detect "eventual consistency delay"

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

Re: MongoMK failover behaviour.

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.

Re: Intent to backport OAK-6953

+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

Intent to backport OAK-8351

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

Re: [DISCUSS] Branching and release: version numbers

+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

Re: fixVersion

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

Re: Merging of the Full-GC feature branch into trunk (OAK-10739)

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

Merging of the Full-GC feature branch into trunk (OAK-10739)

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.