-
Enhancement
-
Resolution: Won't Do
-
Major
-
None
-
None
-
None
There is an EJB performing a nightly clean-up job:
https://github.com/aerogear/aerogear-unifiedpush-server/blob/1.1.x-dev/service/src/main/java/org/jboss/aerogear/unifiedpush/service/metrics/DeleteOldPushMessageInformationScheduler.java
this EJB uses, under the covers, an awful JPQL statement, containing one sub-select query:
https://github.com/aerogear/aerogear-unifiedpush-server/blob/1.1.x-dev/model/jpa/src/main/java/org/jboss/aerogear/unifiedpush/jpa/dao/impl/JPAPushMessageInformationDao.java#L113-L125
Besides that, it looks like on MySQL/InnoDB it can cause a deadlock:
mysql tables in use 1, locked 1
LOCK WAIT 7 lock struct(s), heap size 1248, 25 row lock(s)
MySQL thread id 1452376, OS thread handle 0x7fa376bf8700, query id 36031952 10.71.10.87 unifiedpush updating
delete from push_message_info where submit_date<'2017-01-08 00:00:00'
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 488 page no 3 n bits 112 index `PRIMARY` of table `unifiedpush`.`push_message_info` trx id EC70ED lock_mode X locks rec but not gap waiting
- is related to
-
AEROGEAR-3240 UPS Query improvements and Hibernate Cache tweaks
-
- Resolved
-
- relates to
-
AEROGEAR-3227 UPS deadlock on DB - using more AG UPS in cluster
-
- Resolved
-