Aeron档案的recordingId为何在相同录音时增加？

huangapple
go评论67阅读模式
英文:

Why does Aeron Archive recordingId increase for same recording?

问题

我有一个根据aeroncookbook.com上的示例拼凑在一起的ArchiveHost。

这个归档主机有一个已记录的Publication。它还有一个Subscription - 所有来自订阅的消息都会“转发”到已记录的Publication。

我有5个市场数据生产者应用程序，它们发布到ArchiveHost的Subscription。一切都正常，但在随机情况下，recordingId似乎会增加。

这是否是预期的？可能是什么原因导致的？在上面的示例中，ArchiveHost从未停止。是否可以添加监听器/日志记录以在增加recordingId时接收更多信息？

我期望recordingId在ArchiveHost运行期间保持不变。

英文:

I have an ArchiveHost, tinkered together according to the examples on aeroncookbook.com.

The archive host has a Publication that is recorded. It also has a Subscription - all messages from the subscription are "forwarded" to the recorded publication.

 private void createArchiveAndRecord() {

        final var archiveContext = new Archive.Context()
                .deleteArchiveOnStart(true)
                .replicationChannel(REPLICATION_CHANNEL)
                .controlChannel(ARCHIVE_CONTROL_REQUEST_CHANNEL)
                .controlStreamId(ARCHIVE_CONTROL_REQUEST_STREAM_ID)
                .threadingMode(ArchiveThreadingMode.DEDICATED)
                .idleStrategySupplier(BackoffIdleStrategy::new)
                .errorHandler(this::errorHandler);

        var mediaDriverCtx = new MediaDriver.Context()
                .errorHandler(this::errorHandler)
                .threadingMode(ThreadingMode.DEDICATED)
                .conductorIdleStrategy(new BackoffIdleStrategy())
                .receiverIdleStrategy(new BackoffIdleStrategy())
                .senderIdleStrategy(new BackoffIdleStrategy())
                .dirDeleteOnStart(true);

        archivingMediaDriver = ArchivingMediaDriver.launch(
                mediaDriverCtx,
                archiveContext
        ); 

        try {

             aeron = Aeron.connect(
                     new Aeron.Context()
                             .aeronDirectoryName(archivingMediaDriver.mediaDriver().aeronDirectoryName())
                             .errorHandler(this::errorHandler)
             );
             archive = AeronArchive.connect(
                     new AeronArchive.Context()
                             .aeron(aeron)
                             .controlRequestChannel(ARCHIVE_CONTROL_REQUEST_CHANNEL)
                             .controlResponseChannel(ARCHIVE_CONTROL_RESPONSE_CHANNEL)
                             .controlRequestStreamId(ARCHIVE_CONTROL_REQUEST_STREAM_ID)
                             .recordingSignalConsumer(new ArchiveActivityListener())
                             .errorHandler(this::errorHandler)
             );

            archive.startRecording(RECORDING_CHANNEL, STREAM_ID, SourceLocation.REMOTE);
            final Publication pub = aeron.addPublication(PUBLICATION_CHANNEL, STREAM_ID);
            final CountersReader counters = aeron.countersReader();
            final int recordingCounterId = awaitRecordingCounterId(counters, pub.sessionId());
            final long recordingId = RecordingPos.getRecordingId(counters, recordingCounterId);

            this.currentState = State.RDY;
            this.subscriptionFragmentHandler.setPublication(pub);
        } catch (InterruptedException e) {
            throw new RuntimeException(e);
        }
    }

I have 5 marketdata producer apps, that publish to the ArchiveHost's Subscription. All works fine, however at random occasions, the recordingId seems to increase:

-rw-r--r--. 1 ec2-user ec2-user 134217728 Jun 11 18:54 0-0.rec
-rw-r--r--. 1 ec2-user ec2-user 134217728 Jun 11 19:20 0-1073741824.rec
-rw-r--r--. 1 ec2-user ec2-user 134217728 Jun 11 19:22 0-1207959552.rec
-rw-r--r--. 1 ec2-user ec2-user 134217728 Jun 11 18:58 0-134217728.rec
-rw-r--r--. 1 ec2-user ec2-user 134217728 Jun 11 19:23 0-1342177280.rec
-rw-r--r--. 1 ec2-user ec2-user 134217728 Jun 11 19:24 0-1476395008.rec
-rw-r--r--. 1 ec2-user ec2-user 134217728 Jun 11 19:26 0-1610612736.rec
-rw-r--r--. 1 ec2-user ec2-user 134217728 Jun 11 19:28 0-1744830464.rec
-rw-r--r--. 1 ec2-user ec2-user 134217728 Jun 11 19:30 0-1879048192.rec
-rw-r--r--. 1 ec2-user ec2-user 134217728 Jun 11 19:33 0-2013265920.rec
-rw-r--r--. 1 ec2-user ec2-user 134217728 Jun 11 19:36 0-2147483648.rec
-rw-r--r--. 1 ec2-user ec2-user 134217728 Jun 11 19:38 0-2281701376.rec
-rw-r--r--. 1 ec2-user ec2-user 134217728 Jun 11 19:38 0-2415919104.rec
-rw-r--r--. 1 ec2-user ec2-user 134217728 Jun 11 19:01 0-268435456.rec
-rw-r--r--. 1 ec2-user ec2-user 134217728 Jun 11 19:04 0-402653184.rec
-rw-r--r--. 1 ec2-user ec2-user 134217728 Jun 11 19:08 0-536870912.rec
-rw-r--r--. 1 ec2-user ec2-user 134217728 Jun 11 19:12 0-671088640.rec
-rw-r--r--. 1 ec2-user ec2-user 134217728 Jun 11 19:15 0-805306368.rec
-rw-r--r--. 1 ec2-user ec2-user 134217728 Jun 11 19:18 0-939524096.rec
-rw-r--r--. 1 ec2-user ec2-user 134217728 Jun 11 19:40 1-2432696320.rec
-rw-r--r--. 1 ec2-user ec2-user 134217728 Jun 11 19:41 1-2566914048.rec
-rw-r--r--. 1 ec2-user ec2-user 134217728 Jun 11 19:43 1-2701131776.rec
-rw-r--r--. 1 ec2-user ec2-user 134217728 Jun 11 19:43 2-2785017856.rec
-rw-r--r--. 1 ec2-user ec2-user 134217728 Jun 11 19:45 3-2801795072.rec
-rw-r--r--. 1 ec2-user ec2-user 134217728 Jun 11 19:48 3-2936012800.rec
-rw-r--r--. 1 ec2-user ec2-user 134217728 Jun 11 19:50 3-3070230528.rec
-rw-r--r--. 1 ec2-user ec2-user 134217728 Jun 11 19:51 3-3204448256.rec
-rw-r--r--. 1 ec2-user ec2-user 134217728 Jun 11 19:53 4-3221225472.rec
-rw-r--r--. 1 ec2-user ec2-user 134217728 Jun 11 19:56 4-3355443200.rec
-rw-r--r--. 1 ec2-user ec2-user 134217728 Jun 11 20:00 4-3489660928.rec
-rw-r--r--. 1 ec2-user ec2-user 134217728 Jun 11 20:02 4-3623878656.rec
-rw-r--r--. 1 ec2-user ec2-user 134217728 Jun 11 20:04 4-3758096384.rec
-rw-r--r--. 1 ec2-user ec2-user 134217728 Jun 11 20:06 5-3858759680.rec
-rw-r--r--. 1 ec2-user ec2-user 134217728 Jun 11 20:07 5-3992977408.rec
-rw-r--r--. 1 ec2-user ec2-user 134217728 Jun 11 20:09 5-4127195136.rec
-rw-r--r--. 1 ec2-user ec2-user 134217728 Jun 11 20:10 5-4261412864.rec
-rw-r--r--. 1 ec2-user ec2-user 134217728 Jun 11 20:11 5-4395630592.rec
-rw-r--r--. 1 ec2-user ec2-user 134217728 Jun 11 22:21 6-10032775168.rec
-rw-r--r--. 1 ec2-user ec2-user 134217728 Jun 11 22:23 6-10166992896.rec
-rw-r--r--. 1 ec2-user ec2-user 134217728 Jun 11 22:26 6-10301210624.rec
-rw-r--r--. 1 ec2-user ec2-user 134217728 Jun 11 22:30 6-10435428352.rec

Is that expected? What could cause this? At no point does the ArchiveHost stop in the above example. Is there a listener/logging I can add to receive more information when a recordingId is increased?

I would expect the recordingId to stay the same for the time the ArchiveHost is running.

答案1

得分: 2

每个出版物的源会话，如果在通道URI上没有设置session-id，则会有自己的录音。如果您希望记录单个发布会话，请找到其会话ID，并将其作为参数添加到录制通道中。

final Publication pub = aeron.addPublication(PUBLICATION_CHANNEL, STREAM_ID);
final String sessionSpecificUri = CHANNEL + " | session-id=" + pub.sessionId();

archive.startRecording(sessionSpecificUri, STREAM_ID, SourceLocation.REMOTE);
英文:

Each source session for a publication will have its own recording if you start recording without setting the session-id on the channel URI. If you wish to record a single publication session then find its session id and add this as a parameter to the recorded channel.

    final Publication pub = aeron.addPublication(PUBLICATION_CHANNEL, STREAM_ID);
    final String sessionSpecificUri = CHANNEL + "|session-id=" + pub.sessionId();

    archive.startRecording(sessionSpecificUri, STREAM_ID, SourceLocation.REMOTE);

huangapple
  • 本文由 发表于 2023年6月12日 13:46:05
  • 转载请务必保留本文链接：https://go.coder-hub.com/76453890.html
  • aeron
  • java
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定