Identify persistent classes with an INT id field in the cache invalidation system [FIXED]

Has anyone come across the exception with DHIS2 (2.39) set-up in a clustered environment? The exception is thrown by the leader.

  • WARN 2023-10-20T15:32:00,166 Fetching new entity failed, failed to execute get query! entityId=86556, entityClass=class org.hisp.dhis.message.UserMessage (BaseCacheEvictionService.java [lettuce-epollEventLoop-7-2])
    org.hibernate.TypeMismatchException: Provided id of the wrong type for class org.hisp.dhis.message.UserMessage. Expected: class java.lang.Integer, got class java.lang.Long
    at org.hibernate.event.internal.DefaultLoadEventListener.checkIdClass(DefaultLoadEventListener.java:155) ~[hibernate-core-5.4.28.Final.jar:5.4.28.Final]
    at org.hibernate.event.internal.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:71) ~[hibernate-core-5.4.28.Final.jar:5.4.28.Final]
    at org.hibernate.event.service.internal.EventListenerGroupImpl.fireEventOnEachListener(EventListenerGroupImpl.java:104) ~[hibernate-core-5.4.28.Final.jar:5.4.28.Final]
    at org.hibernate.internal.SessionImpl.fireLoadNoChecks(SessionImpl.java:1186) ~[hibernate-core-5.4.28.Final.jar:5.4.28.Final]
    at org.hibernate.internal.SessionImpl.fireLoad(SessionImpl.java:1175) ~[hibernate-core-5.4.28.Final.jar:5.4.28.Final]
    at org.hibernate.internal.SessionImpl.access$2100(SessionImpl.java:193) ~[hibernate-core-5.4.28.Final.jar:5.4.28.Final]
    at org.hibernate.internal.SessionImpl$IdentifierLoadAccessImpl.doLoad(SessionImpl.java:2786) ~[hibernate-core-5.4.28.Final.jar:5.4.28.Final]
    at org.hibernate.internal.SessionImpl$IdentifierLoadAccessImpl.lambda$load$1(SessionImpl.java:2767) ~[hibernate-core-5.4.28.Final.jar:5.4.28.Final]
    at org.hibernate.internal.SessionImpl$IdentifierLoadAccessImpl.perform(SessionImpl.java:2723) ~[hibernate-core-5.4.28.Final.jar:5.4.28.Final]
    at org.hibernate.internal.SessionImpl$IdentifierLoadAccessImpl.load(SessionImpl.java:2767) ~[hibernate-core-5.4.28.Final.jar:5.4.28.Final]
    at org.hibernate.internal.SessionImpl.get(SessionImpl.java:983) ~[hibernate-core-5.4.28.Final.jar:5.4.28.Final]
    at org.hisp.dhis.cacheinvalidation.BaseCacheEvictionService.tryFetchNewEntity(BaseCacheEvictionService.java:69) ~[dhis-support-cache-invalidation-2.38.5-SNAPSHOT.jar:?]
    at org.hisp.dhis.cacheinvalidation.redis.CacheInvalidationListener.handleMessage(CacheInvalidationListener.java:114) ~[dhis-support-cache-invalidation-2.38.5-SNAPSHOT.jar:?]
    at org.hisp.dhis.cacheinvalidation.redis.CacheInvalidationListener.message(CacheInvalidationListener.java:74) ~[dhis-support-cache-invalidation-2.38.5-SNAPSHOT.jar:?]
    at org.hisp.dhis.cacheinvalidation.redis.CacheInvalidationListener.message(CacheInvalidationListener.java:58) ~[dhis-support-cache-invalidation-2.38.5-SNAPSHOT.jar:?]
    at io.lettuce.core.pubsub.PubSubEndpoint.notifyListeners(PubSubEndpoint.java:219) ~[lettuce-core-6.2.2.RELEASE.jar:6.2.2.RELEASE]
    at io.lettuce.core.pubsub.PubSubEndpoint.notifyMessage(PubSubEndpoint.java:208) ~[lettuce-core-6.2.2.RELEASE.jar:6.2.2.RELEASE]
    at io.lettuce.core.pubsub.PubSubCommandHandler.doNotifyMessage(PubSubCommandHandler.java:292) ~[lettuce-core-6.2.2.RELEASE.jar:6.2.2.RELEASE]
    at io.lettuce.core.pubsub.PubSubCommandHandler.notifyPushListeners(PubSubCommandHandler.java:223) ~[lettuce-core-6.2.2.RELEASE.jar:6.2.2.RELEASE]
    at io.lettuce.core.protocol.CommandHandler.decode(CommandHandler.java:647) ~[lettuce-core-6.2.2.RELEASE.jar:6.2.2.RELEASE]
    at io.lettuce.core.pubsub.PubSubCommandHandler.decode(PubSubCommandHandler.java:112) ~[lettuce-core-6.2.2.RELEASE.jar:6.2.2.RELEASE]
    at io.lettuce.core.protocol.CommandHandler.channelRead(CommandHandler.java:599) ~[lettuce-core-6.2.2.RELEASE.jar:6.2.2.RELEASE]
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) ~[netty-all-4.1.59.Final.jar:4.1.59.Final]
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) ~[netty-all-4.1.59.Final.jar:4.1.59.Final]
    at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) ~[netty-all-4.1.59.Final.jar:4.1.59.Final]
    at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410) ~[netty-all-4.1.59.Final.jar:4.1.59.Final]
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) ~[netty-all-4.1.59.Final.jar:4.1.59.Final]
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) ~[netty-all-4.1.59.Final.jar:4.1.59.Final]
    at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919) ~[netty-all-4.1.59.Final.jar:4.1.59.Final]
    at io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:795) ~[netty-all-4.1.59.Final.jar:4.1.59.Final]
    at io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:480) ~[netty-all-4.1.59.Final.jar:4.1.59.Final]
    at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:378) ~[netty-all-4.1.59.Final.jar:4.1.59.Final]
    at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989) ~[netty-all-4.1.59.Final.jar:4.1.59.Final]
    at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) ~[netty-all-4.1.59.Final.jar:4.1.59.Final]
    at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) ~[netty-all-4.1.59.Final.jar:4.1.59.Final]
    at java.lang.Thread.run(Thread.java:829) ~

Thanks

@Michael_Mwebaze would you be willing to share your dhis.conf file?

1 Like

Hi @Michael_Mwebaze

Could I also ask to verify the version number? You mentioned it’s version 2.39 so I don’t know why the logs are referring to version 2.38.5-SNAPSHOT? Additionally, I’d recommend with using the latest stable version but not SNAPSHOT so for 2.38 it’s currently 3.38.4.3.

And thanks @alanivey! :slight_smile:

Thanks for getting back to me. I forgot to add that the warning did persist in versions 2.38.5-Snapshot and 2.40. Sample of my config file

connection.rl = psql_host

connection.username = some_username

connection.password = some_password

REDIS Configuration

redis.cache.invalidation.enabled = on

reds.enabled = on

redis.host = redishost

redis.port = 6379

redis.password = radispassword

redis.use.ss1 = false

audit.metadata = DISABLED

audit.tracker = DISABLED

audit.aggregate = DISABLED

encryption.password = some_encry_value

connection.pool.max size = 100

connection.pool.num.helper.threads=10

If it’s possible please test again in a stable version and not SNAPSHOT? Thanks!

I did test with 2.40 as well. org.hisp.dhis.message.UserMessage id is expecting an int but for some reason a long is being passed to it.

1 Like

If you look at CacheInvalidationListener in org.hisp.dhis.cacheinvalidation.redis, the returned value in getEntityId is a Long yet id in org.hisp.dhis.message.UserMessage is int and tryFetchNewEntity in org.hisp.dhis.cacheinvalidation.BaseCacheEvictionService logging it as a warning.
What I am not certain is if it has an effect on the cache validation mechanism

1 Like

So I understand what’s going on. The message table has a messageid column of type bigint. Now hibernate is expecting a long but an Integer is being passed and as a result a org.hibernate.TypeMismatchException is being thrown. You have a similar org.hibernate.TypeMismatchException being thrown for the UserMessage. This time the usermessage table has a usermessageid column of typer integer and Hibernate is receiving a Long. What I am not so sure yet is what effect it has on redis cache invalidation. As a temporary work around I have had to make a few modifications that case the entityId from Long to Integer and back when the class being retrieved is a Message or a UserMessage.

1 Like

I have made a fix for the issue here: fix: identify classes with an Integer ID field [DHIS2-16092] by netroms · Pull Request #15554 · dhis2/dhis2-core · GitHub
I will backport to the 2.40,2.39 and 2.38 versions.

1 Like

Much appreciated @netroms

1 Like