问题标签 [chronicle-queue]

我有一个应用程序将条目写入 Chronicle Queue (V3)，该应用程序还通过在队列中提供索引访问来保留其他 (Chronicle)Maps 中的摘录条目索引值。有时我们找不到我们之前保存的给定条目，我相信它可能与数据块翻转有关。

下面是一个独立的测试程序，可以小规模地重现此类用例。它反复写入一个条目并立即尝试使用单独的 ExcerptTailer 查找结果索引值。一切都很好，直到第一个数据块用完并分配了第二个数据文件，然后检索失败开始。如果增加数据块大小以避免翻转，则不会丢失任何条目。同样使用较小的索引数据块大小，导致创建多个索引文件，不会导致问题。

测试程序还尝试使用并行运行的ExcerptListener来查看显然被作者“丢失”的条目是否曾经被阅读器线程接收 - 它们不是。还尝试从开始到结束重新读取生成的队列，这再次确认它们确实丢失了。

通过代码，我看到在AbstractVanillarExcerpt#index中查找“丢失的条目”时，它似乎成功地从 dataCache 中找到了正确的 VanillaMappedBytes 对象，但确定没有条目并且数据偏移量为len == 0。除了找不到条目之外，在翻转后问题开始发生后的某个时间点，由于传递了一个空文件路径，因此从VanillaMappedFile#fileChannel方法中抛出了一个 NPE。代码路径假定当解析在索引中成功查找的条目时，总是会找到一个文件，但在这种情况下不是。

是否可以跨数据块翻转可靠地使用 Chronicle Queue，如果是这样，我在做什么可能会导致我遇到的问题？

I've been experimenting with Chronicle Queue 4.5.27. We are running some tests on a Windows 7x64 VM (Java x64) and sometimes it seems like Chronicle Queue will not ever release the first file that it creates.

We are configured with MINUTELY roll cycles. 1-3 threads can write and there is a single consumer processing on the other end. I register a StoreFileListener to listen for the onReleased event and I groom the file from there (on Windows it tries a few times because of the known issue with mmap files).

The issue is that I never get a notification about the first file the queue creates and a heap dump shows that someone is holding on to the MappedByteBuffer; otherwise the Queue is working as expected. Is there any reason this might happen?

E.g. I'll see something like this on disk after a while:

20170705-2000.cq4
20170705-2008.cq4
20170705-2009.cq4

Thanks!

我们将事件存储在 Chronicle Queue V4 中，并有一个tailer 来处理它们。其中一些事件过期（不是基于时间，而是被后来的事件取代），因此可以在处理过程中被跳过。

有没有办法更新现有的摘录，即将一个布尔标志“过期”设置为真，这样我们就可以跳过过期的事件？或者是否有另一种解决方案可以通过 Chronicle Queue 实现这一目标？

例如，系统生成事件 A1、B1 和 C1。现在一个事件 B2 到达，使 B1 过时。我们现在可以跳过 B1 而无需进行昂贵的处理。

问候， 约臣

以下代码在第 20 次迭代的第二个断言语句中失败 - 请注意，我只是重新创建导致问题的代码；计数无关紧要，而是写入的字节数。

问题似乎出在 SingleChronicleQueueExcerpts 类中，其中向消息添加了填充以将其缓存对齐到 64 个字节。我没有预料到必须将自己的消息长度添加到我的写入中，但如果编年史队列没有将它自己的标题填充到缓存行边界，这似乎是无法避免的。

提前致谢

我们在低延迟应用程序（在 Linux Centos 机器上）中使用Vanilla Chronicle Queue版本 3.6.0。

有一天，似乎是随机的，我们的客户报告说应用程序中缺少 2.5 秒的响应（我们已经运行了好几个月没有发生这种情况）。我们在延迟时检查了顶层文件，发现当时有一个进程正在运行该flush命令。（上面的屏幕截图发布在下面。）

我们猜测 O/S 将 Chronicle 内存页面刷新到磁盘，这阻止了我们的处理线程继续，直到刷新完成。指向相同结论的另一条信息是内部应用程序统计数据似乎显示延迟发生在线程将新条目写入 Chronicle 的处理点。

如果发生这种情况，我们不确定是什么导致了 Chronicle 刷新，因为当时有很多可用内存（125G 中有 110G 可用）。

所以问题是：

1. 有没有办法知道 Chronicle 何时/是否刷新到磁盘？

2. 什么因素会导致这么长的冲洗时间？（这似乎在这几个月里只发生过一次。）

顶部屏幕截图

从 Chronicle-Queue v4.5.27 开始，似乎需要增强 ServiceWrapperBuilder 以包含 StoreFileListener 分配？如果有一个不同的构造，同样，通过ServiceWrapper队列创建，它是什么？

嗨，我是 Chronicle Products 的新用户，到目前为止，文档/使用看起来很流畅。

虽然我有一个问题，当映射数据在同一主机上的 JVM 之间共享时，等待数据的消费者 JVM 在数据到达时是否会收到任何类型的回调或信号，或者我们是否需要实现自定义回调机制。

想法？

我计划将 Chronicle 4 (SingleChronicleQueue) 用于 IPC 。

我以前使用的是 Chronicle 3 (IndexedQueue)，它不是线程安全的，我曾经为每个线程创建多个队列，但有人告诉我使用 SingleChronicleQueue 我可以为 JVM 中的所有线程使用 1 个队列。

但是，如果 2 个不同的进程试图在同一个编年史队列中同时写入，这是否安全？

是否建议这样做或对于不同的进程我需要创建不同的队列。

我正在尝试将 Chronicle Queue 实施到我们的系统中，并且有一个关于每天滚动文件的问题，但在特定时间根据进程的本地时区。我读了几篇关于如何指定滚动周期的文章，但根据文档，纪元时间按照午夜 UTC 工作。假设每天下午 5 点本地时区运行的进程，我需要做什么来配置滚动周期？有什么建议么？

我正在为我们的一个用例对 Chronicle 队列进行基准测试，并注意到 ExcerptTailer 的 readDocument() API 创建了太多垃圾！JFR 显示，该过程在下面的堆栈中花费了大约 66% 的时间。

我使用的是哪个版本的 Chronicle Queue？

net.openhft：编年史队列：4.5.9

我如何创建队列？

产生了多少垃圾？

3 分钟大约 11 GB

堆栈跟踪

我还尝试了什么？

我使用 JitWatch 并将用于转义分析的字节码大小从 150 字节增加到 516 字节。我注意到 readDocument 方法是 JIT 编译的。

对下一步有什么建议吗？