Skip to Content
Last modified by Erik Bakker on 2024/09/03 13:40
From version 3.1
edited by Eva Torken
on 2024/03/22 15:42
Change comment: There is no comment for this version
To version 4.1
edited by Eva Torken
on 2024/03/26 10:58
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -19,11 +19,11 @@
19 19  
20 20  === 3.2 Analysis ===
21 21  
22 -The problem led us to investigate the health of the H2 database. The database had a very high CPU and had high CPU after the connector underwent auto-healing. After further investigation it seemed that the H2 was reprocessing messages and therefore not taking on new ones.
22 +The problem led us to investigate the queue statistics of the flow responsible for delivering the data. Here, it was seen that data was flowing throught the queue, but in a repetitive pattern. In the runtime statistics a very high CPU was observed. Consequently, the health of the H2 database was investigated. The H2 database was processing the messages repeatedly after the connector had undergone auto-healing. Therefore, it was not processing the new messages.
23 23  
24 24  == 4. Result ==
25 25  
26 -The removal and re-addition of the H2 database caused the H2 database to return to normal behavior. Afterwards, the problem did not reoccur.
26 +The removal and re-addition of the H2 database caused the H2 database to return to normal behavior. Afterwards, the problem did not reoccur. The resetting of the H2 database should also solve the problem. This can be done by moving to Deploy -> Architecture and pressing 'Reset H2'. Do remember that resetting the H2 database or removing and readding it will result in a loss of all the data on the database.
27 27  
28 28  == 5. Suggested Additional Readings ==
29 29  N/A