Last modified by Vincent Massol on 2024/02/26 17:53

<
From version < 1.8 >
edited by Guillaume Delhumeau
on 2019/03/06 15:13
To version < 3.1 >
edited by Guillaume Delhumeau
on 2019/03/06 15:15
>
Change comment: There is no comment for this version

Summary

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  

Get Connected