Possibility of Increased chances of losing events upon system crash in Oak compared to Jackrabbit2

[Chetan Mehrotra <ch...@gmail.com>]

Hi Team,

Wanted to confirm one aspect - Are the chances of losing local events in
case of system crash have increased in Oak compared to JR2?

Currently in Oak any local change is pushed to an in memory queue which
gets processed in asynchronous way by each observation listener. Now lets
say if each such queue has 100 entries and system crashes in between then
all those events would be lost and system would not have any memory of such
changes occurring. Due to this some listeners might miss out on doing some
important processing.

Now based on my limited understanding of JR2 I can make out following. So
correct me if I am wrong here. JR2 had a journal based event generation
logic and any change in repository was posted to the journal. Then
observation events were generated based on this persisted journal. In case
of a system crash there is a very small window of loss where changes have
been made to repo but not persisted to the journal. Otherwise all other
info is present in journal. So in case of system crash once system is
restarted it would be able to process the missed out changed by reading
from journal.

Is the above understanding correct?

Chetan Mehrotra

Re: Possibility of Increased chances of losing events upon system crash in Oak compared to Jackrabbit2

[Chetan Mehrotra <ch...@gmail.com>]

Checked with Marcel on that. In JR2 journal was only used for external
event in a cluster. For local events there was an in memory queue. So there
is no change in possibility of event loss in case of abrupt shutdown
between Oak and JR2 as per current design.

Sorry for the noise.

Chetan Mehrotra

On Mon, Mar 23, 2015 at 9:43 AM, Chetan Mehrotra <ch...@gmail.com>
wrote:

> Hi Team,
>
> Wanted to confirm one aspect - Are the chances of losing local events in
> case of system crash have increased in Oak compared to JR2?
>
> Currently in Oak any local change is pushed to an in memory queue which
> gets processed in asynchronous way by each observation listener. Now lets
> say if each such queue has 100 entries and system crashes in between then
> all those events would be lost and system would not have any memory of such
> changes occurring. Due to this some listeners might miss out on doing some
> important processing.
>
> Now based on my limited understanding of JR2 I can make out following. So
> correct me if I am wrong here. JR2 had a journal based event generation
> logic and any change in repository was posted to the journal. Then
> observation events were generated based on this persisted journal. In case
> of a system crash there is a very small window of loss where changes have
> been made to repo but not persisted to the journal. Otherwise all other
> info is present in journal. So in case of system crash once system is
> restarted it would be able to process the missed out changed by reading
> from journal.
>
> Is the above understanding correct?
>
> Chetan Mehrotra
>