[ 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: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org