Cassandra 4.0 – the open-source distributed NoSQL database used by Apple, Netflix, and Spotify – has been delayed at the 11th hour after a developer spotted a bug in the code.
Project contributors had committed to making the much-anticipated release the most stable yet and wanted to ensure it shipped with no known issues. But the world will have to wait a little longer for the release, previously slated for 8am BST, 19 July.
“In preparing the 4.0 GA release, the Apache Cassandra community identified a fix to be made late Friday. Because of this, the release is being held until the fix is complete. We will share the new release time as soon as we know,” a community spokesperson said.
Apache Cassandra software is released under the Apache License v2.0 and is overseen by a voluntary, self-selected team of active contributors.
Apple engineer and Cassandra contributor Jon Meredith on Friday night requested an extension to the vote to the release the code. “There’s a possible issue with 4.0 instances serializing FWD_FRM message parameters to pre-4.0 nodes that I’m investigating and need a little more time,” the message read.
On Saturday, he said: “I’ve confirmed that the serialization and deserialization of FWD_FRM on 4.0 nodes when communicating with pre-4.0 nodes is incorrect and includes an incorrect single-byte address length.
“Additionally, the logic for whether to use the same messageid when forwarding or not needs to include the base message id as well as the forwarding ids. If there was a single node to forward onto, the forwarded request was not being sent with the correct messageId.”
Further details are available on the issue tracking log, or Jira here.
It says that in a mixed version cluster the problem could cause the pre-4.0 nodes to fail. Also on Saturday, a vote decided to reject the release on technical grounds until the problem has been fixed.
Cassandra 4.0 was set to be the project’s first major release for six years. One of the reasons the community was said to have taken so long over the release was the desire to improve quality. The early years of the project had led adopters to wait until version x.6 was available before upgrading their production clusters. In a bid to avoid this reputation, and set a new standard, the community opted to take its time over the release. ®