mikeb01 on master
[Java] Add toString methods. (compare)
mikeb01 on master
[Java] Update documentation. (compare)
mikeb01 on master
[CodeQL] Disable integer as enu… [Java] Make null checks clearer. (compare)
mikeb01 on master
[C] Remove unused media driver … (compare)
mikeb01 on 1.40.0_tutorial_patch
[Java] Fix basic auction clust… (compare)
mikeb01 on master
[Java] Add deprecated tags to d… (compare)
mikeb01 on master
[Java] Deprecate dynamic join. (compare)
mikeb01 on master
[C] Use int64 when parsing uint… (compare)
mikeb01 on master
Set max of resource free queue … (compare)
mjpt777 on master
[Java] Flip buffer for writing. (compare)
mjpt777 on master
[Java] Add defaults to switch s… (compare)
mjpt777 on master
[Java] Use Object streams in tr… (compare)
AeronStat
NAK
s are consistently increasing, +1 every 20 sec or so
LossReport
but the timestamps don't match
LossReport
:AeronStat
is enough: NAKs received
& Retransmits sent
should mean it's receiving NAK from the other media driver
LossReport
is filled with rows starting from 07:42. Around 280 rows for that stream id.
@entangled90 If you need more detailed help we can provide consulting.
atm we are still assessing aeron, I'll let you know in the future
I think there is a bug in aeron IPC.
I run aeron archive on the channel say ipc stream id 1001
I publish thing in order,
but the subscriber read message 100057 before 100055, out of order and shown in log
The archive, however is totally in correct order.
Aeron version i use is 1.28.2
i wonder if such is a know issue or not.
LogInspector
on the log buffers to see contents. Are you certain the logic of your usage is correct? Subscriptions are not concurrent so each thread requires its own instance.
I have been looking at the design of the TimerService in Aeron Cluster and it places strict requirements on the ClusteredService to always call scheduleTimer in the same sequence after a replay or snapshot and subsequent replay.
The constraint of a ClusteredService to not do anything completely non-deterministic i.e. new Random() etc - feels reasonable to me.
However, it also requires ClusteredService to record and restore all its state in a snapshot in order to correctly call scheduleTimer() for it to be reliable. While strictly speaking the snapshot of a ClusteredService should store its entire state. Sometimes a user may only store a subset of the ClusteredService state when snapshotted, this may still result in correct behavior of the ClusteredService however it may not be a deterministic sequence of “schedule” and “cancel” calls to the TimerService therefore it may be doing NoOps when an attempt to schedule following the loading of the snapshot.
I did see the javadoc on the Cluster does hint at this.