[
https://issues.apache.org/jira/browse/JAMES-3559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17335214#comment-17335214
]
Benoit Tellier commented on JAMES-3559:
---------------------------------------
> For me it's new, so I'm trying to dig to find potential issues
Having it as an experimental feature would be the best way to test this out. If
it is not interesting we should make it very clear that we could drop this
anytime.
Also configurable and disactivated by default.
Under these assumptions would it be acceptable?
> what happens if the server breaks while buffering?
Buffered events are lost but resynchronisation will eventually catch up on the
next event (as it uses an event log).
> what happens if a user receives continuously email at a specific rate (1 per
> second for example)?
One notification sent for each debounce so you receive one notif for 2 emails
which seems acceptable.
> what is the risk of the buffer increasing the memory usage in case of too
> many events buffered?
Behind the scene there is a reduce: only the latest state is kept: no memory
footprint.
> JMAP PUSH: window events on the server side?
> --------------------------------------------
>
> Key: JAMES-3559
> URL: https://issues.apache.org/jira/browse/JAMES-3559
> Project: James Server
> Issue Type: Improvement
> Components: JMAP
> Affects Versions: 3.6.0
> Reporter: Benoit Tellier
> Assignee: Antoine Duprat
> Priority: Major
> Time Spent: 50m
> Remaining Estimate: 0h
>
> h3. Why?
> Today a JAMES action might trigger several events being dispatched on the
> event bus (eg moving 2 messages will end up firing 2 additions and 2
> deletion) resulting in likely 4 StateChanges being pushed to the end user.
> h3. How?
> Using the reactor library, James can likely delay pushes for a given
> timewindow and merge the state changes together in order to supply the client
> with only one state change.
> A likely time value might be 2 seconds.
> - Pros: avoid event storm and will lower re-synchronization request count
> (good for perf?)
> - Cons: delays of 2s for real time across devices.
> We could of course make it configurable via a jmap.properties configuration.
> {code:java}
> # Optional. Omiting this property leads to windowing being disables. James
> will
> # then directly forward all StateChanges to the end user without attempting
> to
> # buffer and aggregating them.
> # If specified, James will delay stateChanges for that given amout of time
> and will attempt
> # to aggregate subsequent state changes together before returning them to the
> client.
> # Units: ms, s, min, h, d
> push.aggregation.window.duration=2s
> {code}
> Thoughts [~inputmice] maybe?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
