RabbitMQ WTFs

Bulb

@LaoC There is a tool that tells you the last transaction number, so you have to call that on all the nodes and tell the one with the highest value to just go ahead and start. Now in the start-up script, you Could™ run the tool, publish the number somewhere, then when all the numbers are published, adjust the options.

… but it brings another question: Why in the name of Anoia do you want to use MariaDB in the first place? In clustered mode to top it off. It isn't considerably faster than the alternatives any more, just has more quirks and limitations.

(We used it for HistericalRaisins™; most agreed it was a bad choice)

BernieTheBernie

@Bulb said in RabbitMQ WTFs:

the Kafkaesque messaging provided by Azure defaults to 1 … which … is a bit confusing whether it means 1 day or 1 hour — the list shows it in days, terraform sets it in days, but the label in portal says it's set in hours

If only there was some type safe way to set a time to live ... Something like a System.TimeSpan perhaps...

dkf

@LaoC said in RabbitMQ WTFs:

MariaDB can be a PITA, especially when none of the nodes is convinced it's the last one alive that you can safely restart from. We have one distributed over three locations and they never really go down together but there have been some hard lockups that might as well have been power failures.

Ah yes, a distributed lack-of-consensus algorithm.

Bulb

@BernieTheBernie It's JSON. JSON. JSON!!11!!!!¹

¹ That does not need to be a problem if the JSON has a schema and this JSON does have a schema. So they could be using a duration (as an iso-8601 string, but it would still be unambiguous). But they ain't. I blame most programmers not having much lessons in physics².
² The physics teacher was the one who always insisted on stating the units and told us to do dimensional analysis as a check on the expression before punching it in the calculator and asked whether that's in apples or elephants when someone forgot to write the units to all numbers³. Because in physics the units kinda matter even though the SI system makes it quite a bit easier by having one obvious base to convert everything to.
³ We did that too whenever asked to explain something to a younger or dumber colleague and they made that mistake.

dkf

@Bulb said in RabbitMQ WTFs:

Because in physics the units kinda matter even though the SI system makes it quite a bit easier by having one obvious base to convert everything to.

You still have dimensionless constants to worry about...

Bulb

@dkf Dimensionless constants are dimensionless because they don't depend on the choice of units. And since high school-level physics does not take one anywhere near the fine structure constant, the only ones to worry about are the ½s and 2s that come from integration/differentiation and some πs in electromagnetism.

dkf

@Bulb There's also a few relating to integration around a circle and across a sphere.

Bulb

@dkf Whatever. Scalars exist, but the point is that time interval is not a scalar but a dimensional quantity but most programmers don't bother treating it as one. While physicists are a lot more careful distinguishing the two things.

dkf

@Bulb said in RabbitMQ WTFs:

physicists are a lot more careful distinguishing the two things

That's why there often classes called something like Duration and separate classes called TimeStamp or Instant or something like that. Those aren't simple concepts at all.

PleegWat

@Bulb IME most of the dimensional mistakes with time are between moments in time and intervals, and I don't think physics distinguishes those.

Bulb

@PleegWat Well, there are a couple of relative/absolute quantity pairs in physics. The absolute is then represented as relative to appropriate origin, so the unit is the same, but you have to know which is which, because you can't meaningfully add absolute values (except to average them, which works just fine).

Bulb

@dkf said in RabbitMQ WTFs:

@Bulb said in RabbitMQ WTFs:

physicists are a lot more careful distinguishing the two things

That's why there often classes called something like Duration and separate classes called TimeStamp or Instant or something like that. Those aren't simple concepts at all.

And then it's further complicated by calendars. Because P1D is totally not the same as PT24H.

On a side note, does anybody know when 2022-01-30/P1M ended?

PleegWat

@Bulb said in RabbitMQ WTFs:

On a side note, does anybody know when 2022-01-30/P1M ended?

SQL> select to_date('20220130','YYYYMMDD') + interval '1' month from dual;
select to_date('20220130','YYYYMMDD') + interval '1' month from dual
                                      *
ERROR at line 1:
ORA-01839: date not valid for month specified

Kamil Podlesak

@Bulb said in RabbitMQ WTFs:

On a side note, does anybody know when 2022-01-30/P1M ended?

Is it a nasal daemon territory?
I am pretty sure there is a library somewhere in the wild that interprets this as "it never ends".

dkf

@Bulb said in RabbitMQ WTFs:

On a side note, does anybody know when 2022-01-30/P1M ended?

Using Tcl's date handling (which has had the most thoroughly obsessive handling of these civil calendar issues I know of, by someone very smart who actually had experience of bad they get) I get a sensible answer:

% clock format [clock add [clock scan 01/30/2022] 1 month 1 day -1 second]
Mon Feb 28 23:59:59 GMT 2022

(The 1 day -1 second is because otherwise we get the start of the day.)

I don't need that level of obsessive correctness in my apps; I use POSIX timestamps and don't care about intervals in anything other than seconds. But you might.

Bulb

@dkf said in RabbitMQ WTFs:

because otherwise we get the start of the day

I think the start of the day would be correct, actually ~~(the midnight is an instant; the second the clock showed 2022-03-01T00:00:00 was from the instant itself until one second later, and thus clearly after the end of the interval)~~.

… anyway, yeah, I suppose that's the only possible answer.

LaoC

@Bulb said in RabbitMQ WTFs:

@LaoC There is a tool that tells you the last transaction number, so you have to call that on all the nodes and tell the one with the highest value to just go ahead and start. Now in the start-up script, you Could™ run the tool, publish the number somewhere, then when all the numbers are published, adjust the options.

I know, that's mainly what the PITA is.

… but it brings another question: Why in the name of Anoia do you want to use MariaDB in the first place? In clustered mode to top it off. It isn't considerably faster than the alternatives any more, just has more quirks and limitations.

(We used it for HistericalRaisins™; most agreed it was a bad choice)

Everybody knew MySQL, all applications were tailored to it, and the only two guys with more than a passing knowledge of Postgres clustering said it's even more of a hack. Any other contenders?
TBH most of our dozen clusters just chug along quietly and as long as applications don't insist on running huge transactions they get years of uptime and are really benign wrt upgrades; I've switched distributions and done an upgrade from 10.3 to 10.6 (Galera 3 to 4) without downtime. Only the one distributed between continents has been troublesome, and from what I hear that's still relatively little trouble compared to getting other systems to perform in a scenario like this.

Gribnit

@Bulb said in RabbitMQ WTFs:

when the operator comes to work and starts some extra reader

Yikes, when a monitor on the depth could have kicked up and spun down a reader on its own?

Gribnit

@dkf I've made Java 5's time system behave with similar sanity, using a couple-three heuristics.

Bulb

@Gribnit If the reader is just overloaded, sure. If the reader is crashing because one of the messages is triggering a bug, you won't get anywhere without human intervention.

Gribnit

@Bulb said in RabbitMQ WTFs:

@Gribnit If the reader is just overloaded, sure. If the reader is crashing because one of the messages is triggering a bug, you won't get anywhere without human intervention.

In RabbitMQ, no. However, in Kafka (and with only-once) the non-bug-triggering messages would be able to proceed.

Bulb

@Gribnit That implies, however, that the bug-triggering messages would not be processed after the bug is fixed. Which for some projects is a fatal flaw.

dkf

@Gribnit said in RabbitMQ WTFs:

@dkf I've made Java 5's time system behave with similar sanity, using a couple-three heuristics.

The new Java time system is relatively highly regarded, yes. The old one was terrible.

Kamil Podlesak

@dkf said in RabbitMQ WTFs:

@Gribnit said in RabbitMQ WTFs:

@dkf I've made Java 5's time system behave with similar sanity, using a couple-three heuristics.

The new Java time system is relatively highly regarded, yes. The old one was terrible.

The "new Java system" is there since version 8. Version 5 had still the "old" crazy one.

About about the "high regard"... I've met few people (even on this forum I believe) with very strong opinion that "this is heap of , this whole Instant vs DateTime vs LocalDateTime, just an artificial difference to make like harder"

dkf

@Kamil-Podlesak said in RabbitMQ WTFs:

The "new Java system" is there since version 8. Version 5 had still the "old" crazy one.

There was Joda Time.

About about the "high regard"... I've met few people (even on this forum I believe) with very strong opinion that "this is heap of , this whole Instant vs DateTime vs LocalDateTime, just an artificial difference to make like harder"

They're right, except the problem is that civil time really is that damn messy. Blame people, not computers.

Bulb

@dkf said in RabbitMQ WTFs:

@Bulb said in RabbitMQ WTFs:

On a side note, does anybody know when 2022-01-30/P1M ended?
Using Tcl's date handling (which has had the most thoroughly obsessive handling of these civil calendar issues I know of, by someone very smart who actually had experience of bad they get) I get a sensible answer:
% clock format [clock add [clock scan 01/30/2022] 1 month]
Mon Feb 28 00:00:00 GMT 2022

That seems to be the correct answer (normally one either wants just the date, so the hour does not matter, or actually wants start of the day anyway). That is, the day should be capped to the number of day in the resulting month.

However, GNU date does

$ date --date='2022-01-30 + 1 month'
Wed Mar  2 00:00:00 CET 2022

… that's clearly bogus.

Gribnit

@Bulb yeah that's January plus a January. That was the same diffs as the annoy-ass bug I had to go after o so long ago itself, iirc, btw.

Kamil Podlesak

@dkf said in RabbitMQ WTFs:

They're right, except the problem is that civil time really is that damn messy. Blame people, not computers.

As one wise man said, time is a human invention. We need to know: from when, to when and how much for it.

@Bulb said in RabbitMQ WTFs:

@dkf said in RabbitMQ WTFs:
@Bulb said in RabbitMQ WTFs:

On a side note, does anybody know when 2022-01-30/P1M ended?
Using Tcl's date handling (which has had the most thoroughly obsessive handling of these civil calendar issues I know of, by someone very smart who actually had experience of bad they get) I get a sensible answer:
% clock format [clock add [clock scan 01/30/2022] 1 month]
Mon Feb 28 00:00:00 GMT 2022
That seems to be the correct answer (normally one either wants just the date, so the hour does not matter, or actually wants start of the day anyway). That is, the day should be capped to the number of day in the resulting month.

However, GNU date does
$ date --date='2022-01-30 + 1 month'
Wed Mar  2 00:00:00 CET 2022
… that's clearly bogus.

Both makes sense, it depends on who pays whom (see above).

BernieTheBernie

@dkf said in RabbitMQ WTFs:

@Bulb said in RabbitMQ WTFs:

physicists are a lot more careful distinguishing the two things

That's why there often classes called something like Duration and separate classes called TimeStamp or Instant or something like that. Those aren't simple concepts at all.

Remember my old post about my genius cow-orkers converting temperatures and temperature differences between Celsius and Kelvin?
Like 20C in office, 2C outside, difference 18C
=> 293K in office, 275K outside, difference 291K.
That is obviously not a simple concept at all...