Wojtek

> In 'AbstractMessageReceiver->addPacket',I intercepted the packet and serialized it into a string. After processing through the grpc program, return to the program, convert the string into a packet, call the...

We already set this property: https://github.com/tigase/tigase-utils/blob/f681e263b95013886a983c9b0706c2c391cfd2ba/src/main/java/tigase/util/dns/DNSResolverDefault.java#L170-L170 Your instance should reconnect correctly after 2 minutes thuen.

> In the comment I see: "we are caching ourselves" what does this exactly mean? There is some other cache level somewhere else? There is a cache for IP and...

> ok but this should not interact / cache the dataSource uri, right? Correct, internal cache of DNS resolver is only used in XMPP layer. DNS resolution for data sources...

Indeed, if there is no disconnection then the existing database connection pool will remain with all the connections. If you open mysql connection from the shell and do the failover...

So, they ran into the same issue but reading your previous comment: > as in the comment it seems that short after the failover the DNS still point to the...

I filed a ticket for it (ref: server-1354) but it's not on our immediate agenda and doesn't have ETA.

Hmm, most database exceptions (and this is just a SQLException in the end) should yield an error returned. Could you share ST/error log from the case resulting in message loss?

Tigase in general operates in async manner (it's based on message passing, so in a way it's event based). In this case there should be an error returned, we will...

> after the `networkaddress.cache.ttl` it should start to resolving the correct DNS entry for database and stop logging errors but I left it also for 10 minutes and nothing change,...