znep
Joined 13 years ago
Joined 13 years ago
It is far from certain that any application has such a "steady state", most of the ones I've worked on sure don't. There are obviously ways to analyze things and correlate enqueued and dequeues, but it is far from as simple and black and white as you suggest, especially with truly distributed systems and unknown cause of the reported behavior.
Heck, we don't even know if the messages are being "dropped" or just duplicated.
Then, the entire point for some lawsuits existing is to set the stage for that information to come out for no good legal reason.
You can think of it as legal hacking.
I regret writing that last sentence.
No idea how far between concept and reality that is and obviously this is a whole different class of vehicle than a tank.
Modules are also part of the reason why so many folks got "stuck" on java 8.
It is definitely an interesting study in the challenges of trying to make advances in a platform when a lot of the ecosystem is very much in maintenance mode and may not have a lot of eyes on the combination of existing libraries vs new versions of Java.
It looks like the Spring code, when written, did properly filter out existing unsafe methods in java.lang.Class deliberately. Obviously not in a defensive enough way to avoid this, but adding methods to java.lang.Class is a very rare event.
I know there are other AWS features/services that are lined up behind that validation for FIPS support.
(DON'T ACTUALLY DO THIS on anything other than a personal test db as it will kill all the connections it has permission to kill)
Related, postgres has a number of different volatility options for functions so you can declare if there are side effects: https://www.postgresql.org/docs/14/xfunc-volatility.html These can become very important in some cases to let the optimizer have the freedom to shine.