From version < 8.4 >
edited by Vincent Massol
on 2019/03/06 15:27
To version < 9.1 >
edited by Vincent Massol
on 2019/03/06 15:28
< >
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -102,6 +102,7 @@
102 102  * "Event Status" are generated for users who never goes to the wikis, which is a waste of resource.
103 103  * The "Event Status" table should probably be cleaned regularly to avoid having too much data, meaning some precious notifications could be lost while a user is absent (like a 2 weeks holidays).
104 104  * **This mechanism cannot be applied for the Notifications Macro (that was designed to replace the Activity Stream), so it means both mechanism should co-exists.**
105 +* A thread pool is required anyway, see Solution 1B.
105 105  )))
106 106  )))
107 107  )))
... ... @@ -110,6 +110,7 @@
110 110  
111 111  * Which store should be used to sore the "Event Status" table? Currently, it is a table in hibernate, but SOLR could be considered, or any NoSQL solution.
112 112  * Does it scale?
114 +** How long does it take to perform 200K writes (this is what would happen for a wiki with 200K users when everyone is subscribed to the right events and a page is modified for ex)?
113 113  
114 114  = Temporary conclusion =
115 115  
ProposalCode.ProposalClass[0]
Participants
... ... @@ -1,0 +1,1 @@
1 +xwiki:XWiki.gdelhumeau,xwiki:XWiki.ThomasMortagne,xwiki:XWiki.VincentMassol

Get Connected