我正在使用 Chronicle-queue (5.16.13) 将 json 值写入和读取到编年史文件。要编写对象，我在循环中使用以下内容

并阅读项目我在循环中执行以下调用

我观察到变量currentOffset没有改变，并且在一段时间后（取决于有效负载大小，似乎）循环变为无限并且当前偏移量具有疯狂的值。第一个循环的输出（缩短）是

对于第二个循环

我做错了什么吗？那么有人可以提示我正确的用法吗？

非常感谢！

编辑：添加了最小的工作示例

以下单元测试对我来说失败了。

输出是

我为此打开了一个问题：https ://github.com/OpenHFT/Chronicle-Queue/issues/534

我正在尝试使用 StoreFileListener 实现定期的旧队列文件清除逻辑。我正在使用最新版本的 net.openhft:chronicle-queue:5.16.13。我遇到的问题是：由于下一个循环处于活动状态，滚动循环文件滚动后，我删除了刚刚在 StoreFileListener 中发布的队列文件，然后我创建了一个新的 tailer 并尝试读取消息。它低于 NPE：

如果我创建一个指向相同队列目录的全新队列并创建一个tailer，也会发生同样的情况。

在尝试实现队列文件清除逻辑时看到下面的 NPE 异常：

要重现的测试用例如下：

我想建立一个微服务系统，我正在选择消息队列。作为标题，我可以将 Chonicle 队列用作发布/订阅系统吗？我读到 Chronicle Queue 可以用作同一台机器上的 jvm 之间的消息传递，但是我们如何在不同的机器上实现这一点呢？如果我们使用复制，我们在网关主机上创建一个源队列并将其复制到子服务机器（接收器），这样我们就可以将消息从网关传递到子服务。我们如何从子服务到网关反之亦然？

我使用 CQ v5.16.11（带有 openjdk 11）来保存每日滚动周期的数据。这个过程从周日到周五不间断地运行，所以我每周有 5 个 cq4 文件。我运行了 1.5 周，有 8 个文件（第 1 周 3 个，第 2 周 5 个）。

所以我拥有的文件是：

请注意 20181006.cq4 (cycle=17810) 的缺失文件，因为该过程在星期六不运行。

我使用此代码读取数据：

这会正确读取第一周的数据，但不会读取第二周的数据，因为它不会自动滚动到下一个周期。

知道为什么会发生这种情况或如何解决这个问题吗？

这个问题与旧版本的问题类似

• 从编年史队列中读取消息不会自动将当前索引移动到下一个周期
• 我创建了一个每天滚动的队列

日志：

[编辑 1]： 上周末也发生了同样的事情，即，正如预期的那样，10 月 13 日没有新文件。现在我有 10 月 7 日到 10 月 15 日的文件（缺少 10 月 13 日的文件）。如果我这样做tailer.toStart(); while(tailer.readBytes() { ...}，它只会从 10 月 7 日到 10 月 12 日读取文件，而不会读取 10 月 14 日和 15 日的文件。

[编辑 2]：将问题复制如下 Chronicle-Queue/issues/537

1. 设置/库： jvm openjdk 11、Ubuntu 16.04、openhft.affinity/3.1.9、chronicle-map/3.16.0、chronicle-queue/5.16.11、chronicle-bytes/1.16.23、chronicle-core/1.16.20 ，编年史线/1.16.16，编年史线程/1.16.3，jna/4.4.0
2. 脚步：
   • 启动 WriterProcess - 让它完成。
   • 启动 ReaderProcess - 查看 5 个打印语句。
   • 停止 ReaderProcess
   • 等待一段时间 - 10 分钟。
   • 再次启动 WriterProcess - 让它完成或继续运行这个过程。
   • 启动 ReaderProcess - 它只打印前 5 个打印语句，此后不打印任何内容。即使 WriterProcess 正在运行/写入以排队，该进程中的尾部也不会向前移动。

我想实现交易匹配。我可以在其中使用编年史吗？以及如何使用它？

谢谢。我正在用它写日志。但是发生了一些错误，例如：

有问题的框架：

J 927 C2 net.openhft.chronicle.wire.BinaryWire.copyOne(Lnet/openhft/chronicle/wire/WireOut;)V (751 bytes) @ 0x000000011291e0d4 [0x000000011291ce20+0x12b4]

注册到内存映射：

RAX=0x0000000797b8ba58 是一个 oop [C - klass: {type array char} - 长度：76 RBX=0x0000000000c00000 是一个未知值 RCX=0x0000000000000007 是一个未知值 RDX=0x0000000797b8ba40 是一个 oop java.lang.StringBuilder - klass /lang/stringBuilder'rsp = 0x0000700752b3a0指向线程的堆栈：0x00007f9cc7806800 rbp = 0x0000000000000000000000F2F7174B是一个未知的值rsi = 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000日。 bytes.MappedBytes - klass: 'net/openhft/chronicle/bytes/MappedBytes'r9 = 0x0000000000000006是一个未知值r10 = 0x0000000001123cffff是一个未知值r11 = 0x00000000000000f2f2f71748是一个未知值r12 = 0x0000000000000000是一个不知名的值R13 = 0x00000001123CFFFF Fortial and 7 insy newonn newone newnony values14 un14 un14 un14 un14 un14 un14 un14 und = r14 une r14 une r14 une r14。
这是 hs_err_pid73671.log 中的信息。我的代码有什么错误吗？

我刚刚从 Chronicle Queue 4.6.109 升级到 5.16.16。自从升级以来，我注意到在我们所有使用 Chronicle Queue 的服务中都有以下形式的警告：

2018-10-16 16:26:58,524 WARN [main] SCQIndexing 花了 256 时间进行线性扫描，从 379578902 到 379580588 = (0x169ff0ac-0x169fea16)=1686
2018-10-16 16:29:19,130​​ WARN [mainok] SCQIndexing 315 us to linearScan by position from 411040047 to 411042086 = (0x18800126-0x187ff92f)=2039
2018-10-16 16:29:40,121 WARN [main ] SCQIndexing Took 73 us to linearScan by position from 415383606 to 415388071 = (0x18c251a7-0x18c24036) = 4465
2018-10-16 16:34:03,655 WARN [main ] SCQIndexing 花了 310 我们从 478146209 到 478150976 的位置进行线性扫描 = (0x1c800140-0x1c7feea1)=4767
...

这是真正值得担心的事情还是仅用于（内部）分析？我可以在我的代码中更改什么来消除这些警告，即减少扫描时间（除了将属性chronicle.queue.report.linear.scan.latency 设置为false）？

我有 1 个SingleChronicleQueue通过 methodWriter 代理 API 附加了不同的消息。

我的阅读器处理程序处理“message1”，并为同一处理程序附加一条不同的消息“message2”，以通过不同的方法（message2（））进行处理。

好的？

或者裁缝是否应该总是写到不同的“Out”队列并让它介于两者之间？

这种方法控制对共享状态的非锁定访问的原因。

我正在使用 Chronicle Queue v5.17.0 来处理消息，我的理解是即使 java 进程死亡，队列也不会丢失消息（由于队列使用由操作系统刷新的内存映射文件）。

如果在将内存内容刷新到文件之前，VM 死机或操作系统崩溃，某些消息会丢失吗？

有没有办法控制消息刷新到磁盘？

谢谢！

在下面的代码中，重新启动 tailer 进程就可以了。但是，重新启动 appender 进程会导致 tailer 无法接收更多消息。有没有办法重新启动附加程序并保持通道打开？

已编辑：以下是我用来始终如一地重新创建问题的完整课程。环境：Ubuntu 18 Chronicle-queue-5.16.9.jar

1) java com.tradeplacer.util.IpcTest 生产者

2) java com.tradeplacer.util.IpcTest 消费者

3）杀死生产者

4）重启生产者

5）注意消费者不再阅读任何东西

I'm using Chronicle V4 proxy API to convert a message into a function call.

When myMethod(Thing a) is invoked after a readOne() call, the 'a' object instance ID is the same each time but the content has the latest state.

Imagine:

Methods fired:

The second call with param 'a' now with different state overrides any previous caches version of 'a' in say a hashmap in memory, because the java object instance ID is the same one when myMethod was invoked initially.

I'm hoping this is some odd in my setup - be good to know if this is by design or just an issue my end.