[prev in list] [next in list] [prev in thread] [next in thread] 

List:       james-dev
Subject:    [jira] [Comment Edited] (JAMES-3559) JMAP PUSH: window events on the server side?
From:       "Benoit Tellier (Jira)" <server-dev () james ! apache ! org>
Date:       2021-04-29 8:03:00
Message-ID: JIRA.13370572.1617951932000.370724.1619683380648 () Atlassian ! JIRA
[Download RAW message or body]


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

Benoit Tellier edited comment on JAMES-3559 at 4/29/21, 8:02 AM:
-----------------------------------------------------------------

> 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?

To answer some of your interrogations:

> This is harder to test

I wrote a test already. BTW realtime notification and websocket from my experience is \
already hard to test.

> 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.


was (Author: btellier):
> 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-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]