vyazelenko on master
[Java] Remove workaround for By… (compare)
vyazelenko on master
[Build] Remove debug output. (compare)
vyazelenko on master
[Java] Build full path to the J… (compare)
vyazelenko on master
[Java] Resolve correct tools.ja… (compare)
vyazelenko on master
[Java] Print Gradle java proper… (compare)
mjpt777 on master
[Java] Improve ReplayMergeTest … (compare)
mjpt777 on master
[Java] Code style. (compare)
vyazelenko on master
[Java] Setup Java toolchain for… [C++] Add debug output to confi… (compare)
mjpt777 on master
[Java] Remove dependency for in… (compare)
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.
Aeron.connect()
) and add a subscription for an endpoint let's say 10.1.1.1:1234
, I work with it for some time, then I close the subscription, close the aeron instance and repeat everything once again. A question: what should I do, and should I, before I start everything over?Hi everybody! Apologies for the newbie question. I am trying to run some of the samples in AWS, between separate EC2 instances, same subnet.
Ping/Pong works perfectly, but I cannot make BasicPublisher/BasicSubscriber talk each other, even via simple unicast UDP.
Publisher (10.0.101.101
):
java -cp ./aeron-all-1.32.0-SNAPSHOT.jar \
-Daeron.sample.embeddedMediaDriver=true \
-Daeron.sample.channel="aeron:udp?endpoint=10.0.101.101:9000" \
io.aeron.samples.BasicPublisher
Subscriber (10.0.101.201
):
java -cp ./aeron-all-1.32.0-SNAPSHOT.jar \
-Daeron.sample.embeddedMediaDriver=true \
-Daeron.sample.channel="aeron:udp?endpoint=10.0.101.101:9000" \
io.aeron.samples.BasicSubscriber
The subscriber always fails to connect:
io.aeron.exceptions.ChannelEndpointException: ERROR - AeronException : ERROR - channel error - Cannot assign requested address (at java.base/sun.nio.ch.Net.bind0(Native Method)): aeron:udp?endpoint=10.0.101.101:9000
Security Groups, NACL and routing seems to be ok. The two instances can ping each other and can send UDP on port 9000 with netcat. I also tried specifying the interface explicitly and nothing changes (instances have a single network interface, anyhow).
I am sure I am missing something stupid.
taggedReplicate
work with C Media Driver?