Changes for page Notifications Optimization

Summary

• Page properties (1 modified, 0 added, 0 removed)
• Objects (1 modified, 0 added, 0 removed)
  • ProposalCode.ProposalClass[0]

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