问题标签 [chronicle]

我看到在编年史地图上迭代的时间非常缓慢——在下面的示例中，在我的 2013 MacbookPro 上，每次迭代超过 100 万个条目需要 93 毫秒。我想知道是否有更好的迭代方法或我做错了什么，或者这是预期的吗？我知道 Chronicle Map 没有针对迭代进行优化，但是几年前的这张票让我期待更快的迭代时间。下面的玩具示例：

输出：完成插入完成启动经过：93327 1000 次迭代

我一直在对 Chronicle 队列进行一些性能测试，但我没有得到 Chronicle 声称的微秒延迟。我有一个作家和读者设置。写入器将当前时间写入队列，读取器从队列中读取并获取当前时间并进行差异获取延迟。我对一百万条消息执行此操作，然后取平均值。

我的作家的代码：

我的读者

我得到了几十甚至几百毫秒的延迟。有什么可以帮助我的吗？我认为我做的事情显然是错误的。

我正在评估 Chronicle Queue 在我们软件中的使用情况，我一定是做错了什么。
我有一个附加程序，可以非常快地写入大约 650k 条目。之后，它停止运行，此时内存已飙升至允许的最大值，并最终达到 OutOfMemory。

这是我的代码：

这是在带有 64 位 JVM 的 Windows 7 x64 中运行的，使用：-Xmx1024m
任何想法我可能做错了什么？

编辑：我有其他信息。我在内存峰值之后拍摄了对象分配的快照。很多对象数组等。 以及当我收到 OOM 错误时的堆栈跟踪。

在 OpenHFT 的 Chronicle Queue 的第 3 版中，ExcerptAppender ()) 上有一个 API 调用，用于请求在下一个摘录完成时nextSynchronous(boolean将队列的内容强制写入磁盘 ( )。fsync'd我在版本 4 中没有看到类似的调用。是否可以使用版本 4 达到相同的效果？

我有一个应用程序将条目写入 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!

我正在玩由 ChronicleMap 支持的 ChronicleSet。我已经做了一些初步测试，这对我们的需求来说非常好。与其他解决方案相比，RAM 使用效率更高，访问时间稍慢，但仍然相当快。

但是，我正在测试的一件事是设置最大条目数，它似乎没有按预期工作。

我正在使用以下代码：

根据文档，这意味着在这种情况下允许的最大条目数为 2M。但是，在测试时，我可以可靠地达到指定最大值的 2 倍，甚至更多，直到我得到这样的异常：

在这种情况下， ChronicleMap 对象调用size()吐出4,079,238。所以我想知道如何设置明确的限制（如上面指定的 2M），并让 Chronicle 在此之后可靠地拒绝任何添加其他元素的请求。

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

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

想法？

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

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

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

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

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