Last I heard even local events can be subject to loss of the user id if so many
events are being processed that ‘compaction’ is used to mitigate the load. Is
this still the case?
Please don’t point people toward the availability of the user id from events
(without full disclaimers) if it will n
This starts to sound like Oak should have an explicit interface to announce the
situation to clients, allowing them to implement their own policy about whether
to attempt a restart or not.
-Rob
-Original Message-
From: Marcel Reutegger [mailto:mreut...@adobe.com]
Sent: Wednesday, Septe
I'm not so sure about the conclusion that because the events of interest are
local you can safely use userData. IIUC under heavy load local events may be
aggregated to mitigate the load and in that process 'localness' is lost...
Can anyone more knowledgeable address that point?
Thanks,
-Rob
--
It would be appropriate to change the warning to warn about concurrent reads as
well. That would help highlight performance risks.
-Rob
-Original Message-
From: Michael Dürig [mailto:mdue...@apache.org]
Sent: Wednesday, April 09, 2014 12:27 AM
To: oak-dev@jackrabbit.apache.org
Subject:
I can't comment to the exact meaning of the warning, but I can say the impact
of reading from multiple threads with one session is a significant concern in
itself given the current implementation of Oak. Under high throughput
conditions the lock contention quickly becomes a significant performa
