From version < 2.1 >
edited by Guillaume Delhumeau
on 2019/03/06 15:14
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.

Get Connected