Refs #29111
This seems only to happen with TLS 1.3. In that case, remaining data in
`transportInBuffer` was left there instead of putting it back onto the
chopping block.
Then `doWrap` was run but `doUnwrap` was never called again because only
the chopping block was checked for outstanding data but not the buffer.
Refs #29110
TLSActor could get caught in a spin-loop on connection termination
because there was an implicit assumption that when inbound is closed
(peer has sent `close_notify`), this SSLEngine would also automatically
send a `close_notify` and close the connection.
Therefore, it would stay in `flushOutbound` pumping in a loop.
This is not true anymore with TLS 1.3, more accurately it can be
configured using `-Djdk.tls.acknowledgeCloseNotify` which is `false` by
default leading to half-open connections.
The solution is to not support half-open TLS connections for now and
consider a connection closed as soon as `isInboundClosed` and there's no
outstanding data.
(To support half-open connections, this fix would have to be reverted
and `flushOutbound` fixed accordingly.)
* when using down-removal-margin it could allocate to an
already terminated region
* the watch fix in PR #29092 solves this
* this is an "optimization" to avoid the regions that
have been terminated
* off by one when accessed from event handler
* off by one from event handler during replay
* wrong when unstashing
* added more tests, also for persist of several events
* Detect duplicate serializer identifiers, #29100
* and expand the documentation for the serializer identifier
* and mention BaseSerializer to read the identifier from config
* same class same id is ok
* change package name to akka.cluster.sbr
* reference.conf has same config paths
* akka.cluster.sbr.SplitBrainResolverProvider instead of com.lightbend.akka.sbr.SplitBrainResolverProvider
* dependency from akka-cluster to akka-coordination, for lease strategy
* move TestLease to akka-coordination and use that in SBR tests
* remove keep-referee strategy
* use keep-majority by default
* review and adjust reference documentation
Co-authored-by: Johan Andrén <johan@markatta.com>
Co-authored-by: Johannes Rudolph <johannes.rudolph@gmail.com>
Co-authored-by: Christopher Batey <christopher.batey@gmail.com>
Co-authored-by: Arnout Engelen <github@bzzt.net>
Refs #28993
The previous `nextDeadline - time < 0` required that nanoTime resolution is
actually high enough to see that the deadline had already passed. If it
had not, the current keep alive was missed and also all future ones (until
another a regular element would trigger another push/pull cycle).
Now, with `>=` it also works in that case and just fails noisily if our
assumptions are not true.
It's not clear how it could have happened. On my machine, timers
trigger 1-2 tick-durations too late (but at least ~2ms). How that could be
the same in terms of the nanoTime resolution is hard to see.
* encode failedFatally in the existing _failed field
* removed unused parameter of finishRecreate
* removed now unused parameter of clearActorFields
* Removed failed fatally with perpetrator state
* Remove actor_= and restrict places where _actor can be set
* test for non null context on actor termination
* Remove Reflect.lookupAndSetField