Hi again ;-)
On 29.1.14 2:46 , [email protected] wrote:
Author: jukka
Date: Wed Jan 29 01:46:43 2014
New Revision: 1562341
URL: http://svn.apache.org/r1562341
Log:
OAK-1332: Large number of changes to the same node can fill observation queue
Implement rate-limiting to of ChangeListener callbacks, as mentioned in the
issue
+ /**
+ * Maximum number of content changes to process during the
+ * execution of a single diff continuation.
+ */
+ private static final int MAX_CHANGES_PER_CONTINUATION = 10000;
/**
- * Create a new instance of a {@code EventGenerator} reporting events to
the
- * passed {@code listener} after filtering with the passed {@code filter}.
+ * Maximum number of continuations queued for future processing.
+ * Once this limit has been reached, we'll start pushing for the
+ * processing of property-only diffs, which will automatically
+ * help reduce the backlog.
+ */
+ private static final int MAX_QUEUED_CONTINUATIONS = 1000;
As mentioned on the issue already I would have waited with that until we
have a at least a better understanding of the limits of the unbounded
approach. In my tests I never saw a significant number of queued events.
Even when sending out millions of events on a heavily loaded system
under memory pressure I never saw more that 1500 queued events.
While I think this approach is way cool, I also think it unnecessarily
complicates ongoing debugging effort of observation issues we face with
client applications.
Michael
