Changes for page Notifications Optimization
Last modified by Vincent Massol on 2024/02/26 17:53
<
>
edited by Guillaume Delhumeau
on 2019/03/06 15:13
on 2019/03/06 15:13
edited by Guillaume Delhumeau
on 2019/03/06 15:15
on 2019/03/06 15:15
Change comment:
There is no comment for this version
Summary
-
Page properties (1 modified, 0 added, 0 removed)
Details
- Page properties
-
- Content
-
... ... @@ -16,6 +16,8 @@ 16 16 17 17 As you can see, the steps 3-4-5 can be executed a lot of times, in bad conditions. It is currently implemented as a recursive algorithm, which could theoretically lead to a stack overflow (see: https:~/~/jira.xwiki.org/browse/XWIKI-15927). 18 18 \\On probematic wikis, I often notice these kind of stacktraces, with a lot of repeating: 19 + 20 +{{code}} 19 19 [...] 20 20 org.xwiki.notifications.sources.internal.DefaultParametrizedNotificationManager.getEvents(DefaultParametrizedNotificationManager.java:142) 21 21 org.xwiki.notifications.sources.internal.DefaultParametrizedNotificationManager.getEvents(DefaultParametrizedNotificationManager.java:142) ... ... @@ -22,14 +22,18 @@ 22 22 org.xwiki.notifications.sources.internal.DefaultParametrizedNotificationManager.getEvents(DefaultParametrizedNotificationManager.java:142) 23 23 org.xwiki.notifications.sources.internal.DefaultParametrizedNotificationManager.getEvents(DefaultParametrizedNotificationManager.java:142) 24 24 [...] 25 -\\So this is exactly what is going on. It means the SQL queries return a lot of events, but almost all of them are filtered by post-filters or are so similar that they are grouped in a few CompositeEvent. 27 +{{/code}} 28 + 29 + 30 +So this is exactly what is going on. It means the SQL queries return a lot of events, but almost all of them are filtered by post-filters or are so similar that they are grouped in a few CompositeEvent. 26 26 \\Some scenarios I can see (in descending order or probability): 27 -A. There is a lot of events in documents that the user is not allowed to see. Adding a filter for the user profile on the restricted space could solve the issue. 28 -B. There is a bug in a post-filter and we need to identify which one and why. 29 -C. There is a lot of "personal messages" (using the Message Sender Gadget) that are filtered only by post-filters (I don't remember why it cannot be expressed with SQL but I had a good reason). 30 -D. The same event is stored multiple times in the database, so it continuously fill the same CompositeEvent. 31 -E. There is a bug in the recursion so the database always return the same results (but it would mean we have an infinite loop, so it would crash). 32 32 33 +* A. There is a lot of events in documents that the user is not allowed to see. Adding a filter for the user profile on the restricted space could solve the issue. 34 +* B. There is a bug in a post-filter and we need to identify which one and why. 35 +* C. There is a lot of "personal messages" (using the Message Sender Gadget) that are filtered only by post-filters (I don't remember why it cannot be expressed with SQL but I had a good reason). 36 +* D. The same event is stored multiple times in the database, so it continuously fill the same CompositeEvent. 37 +* E. There is a bug in the recursion so the database always return the same results (but it would mean we have an infinite loop, so it would crash). 38 + 33 33 == Solution 1 - A: Add a timeout to the query == 34 34 35 35 To avoid an infinite loop, we could simply add a timeout. ... ... @@ -102,7 +102,11 @@ 102 102 ))) 103 103 ))) 104 104 111 +=== Questions to be answered for Solution 2 - C === 105 105 113 +* 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. 114 +* Does it scale? 115 + 106 106 \\ 107 107 108 108