mikeb01 on 1.38.x
Reduce sharing on image endpoin… (compare)
mikeb01 on master
Reduce sharing on image endpoin… (compare)
mjpt777 on master
[Java] Update recordingId on an… Merge remote-tracking branch 'o… (compare)
mjpt777 on master
[Java] When attempting ClientSe… (compare)
vyazelenko on master
[Java] Allow any Agrona version… [Java] Upgrade to Agrona 1.15.2. (compare)
appendPositionL
and commitPositionL
. Next one of the members becomes a candidate while having commitPositionM1
< commitPositionL
< appendPositionM1
< appendPositionL
. So i was wondering what happens when he gets (eventually) elected?commitPositionM1
(just like all the followers do onNewLeadershipTerm
),Hi, we have a multi-socket box and have two processes using Aeron IPC on a different numa node to where the media driver is running. The IPC term buffers are ending up on the media driver node according to /proc/<pid>/numa_maps.
Do we need a separate media driver on the other socket to avoid this?
Hello!
i have a quick question regarding benchmarks
found weird downside when testing on two remote machines:
Subscrbier:
java -cp aeron-all/build/libs/aeron-all-1.34.0.jar -Daeron.sample.embeddedMediaDriver=true -Daeron.sample.channel="aeron:udp?endpoint=0.0.0.0:20006" io.aeron.samples.RateSubscriber
Publisher
java -cp aeron-all/build/libs/aeron-all-1.34.0.jar -Daeron.sample.embeddedMediaDriver=true -Daeron.sample.channel="aeron:udp?endpoint=34.245.39.15:20006" io.aeron.samples.StreamingPublisher
on both machines i adjust $ sudo sysctl net.core.rmem_max=2097152
$ sudo sysctl net.core.wmem_max=2097152 as mentioned in your wiki page.
this is small snapshot:
6336 msgs/sec, 2.027e+05 payload bytes/sec, totals 57032 messages 1 MB
6247 msgs/sec, 1.999e+05 payload bytes/sec, totals 63284 messages 1 MB
6255 msgs/sec, 2.001e+05 payload bytes/sec, totals 69544 messages 2 MB
6288 msgs/sec, 2.012e+05 payload bytes/sec, totals 75838 messages 2 MB
6266 msgs/sec, 2.005e+05 payload bytes/sec, totals 82110 messages 2 MB
6270 msgs/sec, 2.006e+05 payload bytes/sec, totals 88384 messages 2 MB
6269 msgs/sec, 2.006e+05 payload bytes/sec, totals 94658 messages 2 MB
6279 msgs/sec, 2.009e+05 payload bytes/sec, totals 100942 messages 3 MB
6291 msgs/sec, 2.013e+05 payload bytes/sec, totals 107238 messages 3 MB
6292 msgs/sec, 2.013e+05 payload bytes/sec, totals 113534 messages 3 MB
6279 msgs/sec, 2.009e+05 payload bytes/sec, totals 119818 messages 3 MB
Am i missed smth? Do i need to setup specific configuration to run your benchmarks
because for same setup when launched on same machine for udp i get
1.047e+06 msgs/sec, 3.351e+07 payload bytes/sec, totals 1048218 messages 31 MB
8.934e+06 msgs/sec, 2.859e+08 payload bytes/sec, totals 10000000 messages 305 MB
With no changes to our code, but just a restart, we are suddenly facing an unusual ERROR when the Consensus Module is starting up. What could be possible causes? Full stack trace in thread.
ERROR io.aeron.cluster.ConsensusModuleAgent java.lang.IllegalStateException: Cannot assign long arg5 to int
Hi @mjpt777
It's been a while but I'm now looking at adding MDC support to aeron-go.
I was wondering if there is an XML spec for the flyweights used for AddDestination etc? I had a bit of a browse in the aeron git and wiki but failed to find anything.
It all seems pretty transparent from the code - it's just I prefer to start from a spec where possible.
Thanks,
Bill.
Is using ReplayMerge necessary for merging replay with live stream? I guess otherwise it is not trivial to find the
cut off point at which subscriber should consume live stream instead of replayed and guarantee "at most once" delivery.
The problem I am facing is that ReplayMerge does not seem to work where live messages are published and recorded over multicast. I am getting error message "channel does not allow manual control" which I guess means ReplayMerge is tring to add subscription to the publisher which publishes over multicast channel that does not support manual control.
All ReplayMerge examples/tests use MDC so I wonder if multicast is supported for this use case
Thank you, I can get ReplayMerge working now for single publication sessionId. Unfortunately it does not seem to support multiple simultaneous sessions. I have multiple clients publishing to the same streamId over the same multicast channel, each having different sessionId. I tried running one ReplayMerge per session (getting sessionIds from archive recordings) with segregated replayDestinations but ReplayMerge gets confused when attempting to switch to live as it is trying to merge replay that delivers messages from a single session with live stream that delivers events from multiple sessions.
Ideally I would have one recording per streamId instead of the current recording per sessionId. Forcing the shared sessionId on multiple publishers results in archive/subscription treating multiple publications as one session, i.e. removing what it thinks are duplicate message.
ReplayMergeTest
fail (e.g. modify the test and put fail()
or throw exception from it). When the test fails it will capture all of the data (media driver, Archive etc.) and store under the build/test-output
directory (i.e. aeron-system-tests/build/test-output/io.aeron.archive.ReplayMergeTest-shouldMergeFromReplayToLive
).
archiveDir
when the test ends. Thus you can simply navigate to that dir to see what is inside.
./gradlew clean assemble -x javadoc
) and then add the logging options to the test executable. Here is an example which enables admin
events for the media driver and all of the events for the Archive:-javaagent:<path_to_aeron_project>/aeron/aeron-agent/build/libs/aeron-agent-1.38.0-SNAPSHOT.jar
-Daeron.event.log=admin
-Daeron.event.archive.log=all