Clojurians Log v2
datomic
Hello guys, sorry for bothering you in this festive season, gc-storage should collect the storage garbage that was created before the last bugfix right? I mean about this one:
• Fix: Indexing slowly leaks garbage segments in storage which are unrecoverable by gc-storage.
great question, and no it does not make the unrecoverable segments recoverable, it plugs the leak
thank you for the reply 🙂 Anything I can do? Restore from backup?
if you wanted to loosely quantify the amount unrecoverable storage you may have, you could restore a backup into another storage, and compare the sizes
but yes, restoring a backup to a fresh location would have no unrecoverable garbage
thank you!
I know it was fixed in 1.0.7469 but what version was the bug introduced in? It would be helpful for me to correlate our storage spend
years ago
maybe all the way since adaptive indexing like 10 years ago
Introduced back in 2013/2014 I believe
Small Pro datomic.api feature request: it would be pretty useful if there was a supported way to pass in additional configuration options for the Netty connection objects used for the ActiveMQ/Artemis connection to the transactor when creating a Datomic connection object.
Use case I ran into: we're experimenting with running connections over Tailscale in Fargate so we can simplify some network stuff, but using Tailscale on Fargate requires your application to make its connections through a local proxy. This would almost work with the proxy options you can tweak at the JVM level except there's not really any way to convince Netty to defer DNS resolution to the proxy other than passing socksRemoteDNS=true when you build the connections.
(These options would get sent in the same map as the :host, :port, :sslEnabled, :keyStorePath, :keyStorePassword options that already get sent to Netty)