Cherry pick #3627 from Cadence #839
Conversation
|
|
|
|
||
| maxCassandraTTL = int64(630720000) // Cassandra TTL maximum, 20 years in second | ||
| // ref: https://docs.datastax.com/en/dse-trblshoot/doc/troubleshooting/recoveringTtlYear2038Problem.html | ||
| maxCassandraTTL = int64(315360000) // Cassandra max support time is 2038-01-19T03:14:06+00:00. Updated this to 10 years to support until year 2028 |
There was a problem hiding this comment.
Why not:
func maxCassandraTTL() int64 {
return (time.Date(2038,01,19,03,14,06,0,time.UTC).Sub(time.Now().UTC())).Milliseconds()
}
There was a problem hiding this comment.
We have default timeouts of 10 years.
There was a problem hiding this comment.
depending on whether we are still going to support Cassandra after 10 years
the solution from uber is much more simpler.
@samarabbas what do you think?
There was a problem hiding this comment.
Agreed with @wxing1292. The main issue is we need a concept of infinite timeout in Temporal. Using a default of 10 years introduces a scalability bottleneck. Here are couple of issues tracking this:
#358
#573
There was a problem hiding this comment.
This is not even 10 but 8 years. I don't understand why they picked up some random number instead of properly set to the real limit Cassandra gives us. It is used in 2 places only.
There was a problem hiding this comment.
well, I guess as long as the time is really long (far in the future), then it is ok? BTW, cadence picked 5 years...
5 participants
What changed?
Why?
cadence-workflow/cadence#3627
How did you test it?
DB integration tests
Potential risks
N/A