[
https://issues.apache.org/jira/browse/OAK-5740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15876460#comment-15876460
]
Vikas Saurabh edited comment on OAK-5740 at 2/21/17 6:45 PM:
-------------------------------------------------------------
[~egli],
{quote}
bq. may be some util class/method (exposed?? in case some external observer
want it!) would be ok.
what would such a util method do and how would it be used?
{quote}
I was mainly thinking of test scenario. So, I'd have been happy with something
like (ignore syntax and compilation errors :):
{code}
class ConsumingListenerWrapper implements EventListener {
private final EventListener delegate;
private final Session changePusher;
private long addNodeCounter;
private long observedNodeCounter;
private ConsumingListenerWrapper(Session changePusher, EventListener
delegate) {..}
static wrap (Session cp, EventListener el) {return new
ConsumingListenerWrapper(cp, el);}
onEvent(EventList events) {
delegate.onEvent(events);
while(events.hasNext()) {
/*
increment observed nodes
*/
Event e = events.nextEvent();
if (addNodeCount - observedNodeCount < OBS_Q_LENGTH &&
doItOneInThreeTime) {Node n =
changePusher.createNode("/var/<uuid>");changePusher.save();n.remove();changePusher.save();}
}
}
Node addNode(String path) {
addNodeCounter++;
return changePusher.addNode(path);
}
}
{code}
Of course, that's similar to what I did while fixing the test of observation
warn logger test - we could probably do something else entirely.
bq. I'm not proposing that it's realistic that this issue happens, but I don't
think it's only relevant in a test neither.
Ack. I personally don't feel comfortable changing this part of logic - but,
yes, if this is fixed, that's perfectly fine with me.
was (Author: catholicon):
[~egli],
{quote}
bq. may be some util class/method (exposed?? in case some external observer
want it!) would be ok.
what would such a util method do and how would it be used?
{quote}
I was mainly thinking of test scenario. So, I'd have been happy with something
like (ignore syntax and compilation errors :):
{code}
class ConsumingListenerWrapper implements EventListener {
private final EventListener delegate;
private final Session changePusher;
private ConsumingListenerWrapper(Session changePusher, EventListener
delegate) {..}
static wrap (Session cp, EventListener el) {return new
ConsumingListenerWrapper(cp, el);}
onEvent(EventList events) {
delegate.onEvent(events);
while(events.hasNext()) {
Event e = events.nextEvent();
if (lastEventProcessesWas1SecondAgo) {Node n =
changePusher.createNode("/var/<uuid>");changePusher.save();n.remove();changePusher.save();}
}
}
}
{code}
bq. I'm not proposing that it's realistic that this issue happens, but I don't
think it's only relevant in a test neither.
Ack. I personally don't feel comfortable changing this part of logic - but,
yes, if this is fixed, that's perfectly fine with me.
> deliver overflow change even without new commit
> -----------------------------------------------
>
> Key: OAK-5740
> URL: https://issues.apache.org/jira/browse/OAK-5740
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
> Affects Versions: 1.6.0
> Reporter: Stefan Egli
> Priority: Minor
> Attachments: OAK-5740.testcase.patch, OAK-5740.testcase.patch
>
>
> As [reported|http://markmail.org/message/2qxle24f6zu2vpms] by [~catholicon]
> on oak-dev the observation queue only delivers the so-called _overflow
> entry/change_ only when new commits are 'coming in'. We might want to
> consider fixing this, even though arguably this is a very rare case (since
> typically the observation queue is configured to be very large)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
