Hi, I just tested it on my staging environment and the error is fixed (no longer reported in the logs when it boots or when I listsnapshots).
It was indeed an amazing coincidence that the person who maintains that lib also happened to respond to my question :D Thank you so much for walking me through it and providing such a quick fix, even if this had absolutely nothing to do with Cassandra. All the best, Alexandru > On 5 Nov 2025, at 17:44, Štefan Miklošovič <[email protected]> wrote: > > Hey, > > I happen to be the maintainer of that cassandra-ldap plugin. > > I think the problem was this (1) so the deps from that ended up in the > resulting jar ... then you put that on the CP of Cassandra and it got > messed up. > > I have released 4.1.10-1.0.0 version here you can download and try again (2) > > (1) > https://github.com/instaclustr/cassandra-ldap/commit/f5cba27c2ba8cd701270e1b0adbadbd48764a0ed > (2) https://github.com/instaclustr/cassandra-ldap/releases/tag/v4.1.10-1.0.0 > > Regards > > On Wed, Nov 5, 2025 at 3:58 PM Alexandru Ionescu <[email protected]> wrote: >> >> Hi again, >> >> After sending the previous message, I immediately downloaded the jar for >> cassandra-ldap 4.1.8 and decompiled it using jd-gui and indeed it’s >> including Jackson databind. I don’t know which version yet, but most >> probably it’s a transitive dependency. >> >> Thank you so much for pointing me out in the right direction. >> >> >> All the best, >> >> Alexandru >> >> >> >> On 5 Nov 2025, at 16:48, Alexandru Ionescu <[email protected]> wrote: >> >> Hi Štefan, >> >> Thank you for your answer. >> >> As nodes are managed by the k8s operator, they are running >> "k8ssandra/cass-management-api:4.1.6-ubi-v0.1.109”. I checked a production >> node (4.1.6) and indeed I have the specified Jackson databind version: >> >> ls -lath /opt/cassandra/lib/jackson-databind-2.13.2.2.jar >> >> The updated staging node (4.1.10) also has the proper version (image >> "k8ssandra/cass-management-api:4.1.10-ubi-v0.1.109”): >> >> ls -lath /opt/cassandra/lib/jackson-databind-2.19.2.jar >> >> >> The only thing I added to those images was the “cassandra-ldap” library, but >> AFAIK it doesn’t seem to include jackson. Since there is no cassandra-ldap >> targeting 4.1.10 specifically, I used the jar built against 4.1.8. >> >> >> Regards, >> >> Alexandru Ionescu >> >> >> >> On 5 Nov 2025, at 13:15, Štefan Miklošovič <[email protected]> wrote: >> >> Hi, >> >> I have tried this: >> >> 1) node on 4.1.6, creating a snapshot on ks.tb >> 2) started node on 4.1.10 with all data from 4.1.6 >> >> Node just started fine, I do not see any warning like you do. >> >> Also, if you look into 4.1.10's sources, it is using Jackson >> (databind) of version 2.19.2. If you check >> com.fasterxml.jackson.databind.SerializationFeature enum, there is >> WRITE_DATE_TIMESTAMPS_AS_NANOSECONDS and in >> com.fasterxml.jackson.databind.DeserializationFeature there is >> READ_DATE_TIMESTAMPS_AS_NANOSECONDS. >> >> If you look into 4.1.6, it is using Jackson 2.13.2.2 and there are >> also these enums so I am not sure at all what might be the cause of >> the problem. >> >> Even the node booted fine, because it did not load the snapshots, you >> will not see them in the output of nodetool listsnapshots so it is not >> completely "harmless". >> >> Are you sure that you have upgraded it properly, like you upgraded all >> the libs as well and similar? >> >> Could you double check what Jackson libraries the node you see these >> warnings in started with? >> >> Regards >> >> On Tue, Nov 4, 2025 at 10:54 PM Alexandru Ionescu <[email protected]> wrote: >> >> >> Hi all, >> >> I have two Cassandra clusters running 4.1.6 (managed by K8ssandra Operator), >> one for prod and one staging. I would like to upgrade to the latest patch >> version (4.1.10) in order to benefit from the latest patches and bugfixes. >> >> I tried upgrading the staging cluster directly from 4.1.6 to 4.1.10 and it >> seemed to have worked (nodes restarted one by one and came up normally). The >> only strange thing that I saw when looking at the logs was this error: >> >> WARN [main] 2025-10-31 21:18:50,483 SnapshotLoader.java:121 - Could not load >> snapshot from >> /opt/cassandra/data/data/system/compaction_history-b4dbb7b4dc493fb5b3bfce6e434832ca/snapshots/1761945517930-upgrade-4.1.6-4.1.10. >> java.lang.NoSuchFieldError: READ_DATE_TIMESTAMPS_AS_NANOSECONDS >> >> >> This error seems harmless as the cluster is up and running, but I don’t know >> if this is normal or not. >> >> Since I only upgraded to a newer patch version, I assumed I could upgrade >> directly without applying the versions in between. I didn’t find many >> articles online on how I should approach this as most articles are focused >> on major upgrades (like 3.0 -> 4.0). >> >> Should I try upgrading without skipping patch versions or is it fine as I >> just did on my staging cluster? >> >> One final side question: when you do patch upgrades, I presume there >> shouldn't be any need to run sstableupgrade, right? >> >> >> Many thanks, >> >> Alexandru Ionescu >> >> >>
