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 >
