[ 
https://issues.apache.org/jira/browse/JAMES-3559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17317835#comment-17317835
 ] 

Daniel Gultsch commented on JAMES-3559:
---------------------------------------

I think whats important to me is that modifications within the same request 
only trigger one push event. Meaning if I’m flagging 50 messages as read in 1 
request that should trigger on change event. However if I'm firing up 50 
requests that each modify just one email I'd be OK with that creating 50 change 
events.

 

That why the optimization of clustering mass keyword changes into one request 
is within the responsibility of the client.

> 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

Reply via email to