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 > > >
