On 21.9.16 8:50 , Carsten Ziegeler wrote:
On 21.9.16 8:33 , Carsten Ziegeler wrote:
Pushing filters as much into Oak has many performance advantages though
compared to filter messages after delivery. Also Oak would easily able
to support the delete use case described above.
In all cases, always, guaranteed?
For some definition of "all cases, always, guaranteed": yes ;-)
:) So there is no compaction, never?
There isn't if you configure it that way. It's up to you.
But this is completely irrelevant here. If compaction would cause events
to get lost, there is nothing you could do about it in Sling. Regardless
whether you implement an ad-hoc DYI filter in Sling or use Oak filters.
Michael
Carsten
Obviously I'm only speaking for Oak here. Meaning, if you want to cover
deletes in the way described Oak would support that. Obviously there is
nothing Oak can do if other resource providers can't cover the delete
case. At this point it is - as you say - up to Sling to define how to
deal with it at a higher level of abstraction.
Michael
