[
https://issues.apache.org/jira/browse/JAMES-3559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17317794#comment-17317794
]
Benoit Tellier commented on JAMES-3559:
---------------------------------------
> I'm not sure to get the improvement. Can you add an example of the 2 adds / 2
> deletions versus the consolidated events?
Let's say flagging 50 messages as seen. If it is a disjoint id set, (1, 3, 5,
..., 101) then 50 calls to messageIdManager::setMessages will be generated, 50
FlagsUpdated events will be fired, 50 StateChange event will be handed to the
client, which 'might' do 50 resynchronisation (1 /changes call piped with one
or several /get call) which means hundreds of resynchronisation requests...
With (say) a 2 second bufferisation these 50 stateChanges notification would be
buffered in one, with only one resynchronisation.
> By the way 2s sounds like a human temporization. Here the events are machine
> generated, so why not a low value such as 100ms?
To that I answer: it's configurable, and can be disabled, so that people can
choose to do what they want on their instances.
> 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
>
> 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: [email protected]
For additional commands, e-mail: [email protected]
