问题标签 [chronicle]

不久前，我问了这个关于 ChronicleMap 被用作Map<String,Set<Integer>>. 基本上，我们有一个集合，其平均值Set<Integer>可能为 400，但最大长度为 20,000。在 ChronicleMap 2 中，这导致了相当严重的 JVM 崩溃。我搬到了 ChronicleMap 3.9.1 并且现在已经开始出现异常（至少它不是 JVM 崩溃）：

我怀疑这仍然是因为我的值与平均值相差甚远。我假设 ChronicleMap 根据我给构建器的平均值确定最大块数为 6328，但没想到会有一个需要 23045 个块的巨大值。

所以我的问题是：解决这个问题的最佳方法是什么？我正在考虑的一些方法，但仍然不确定：

1. 使用ChronicleMapBuilder.maxChunksPerEntry或ChronicleMapBuilder.actualChunkSize。也就是说，我如何确定性地确定应该设置什么？此外，如果设置得太高，这可能会导致大量碎片和性能下降，对吧？
2. 有一个“最大集合大小”并将非常大的集合分成许多较小的集合，相应地设置密钥。例如，如果我的密钥XYZ产生Set<Integer>大小为 10000 的密钥，也许我可以将其拆分为 5 个密钥XYZ:1、XYZ:2等，每个密钥的大小为 2000。这感觉就像我可以在 ChronicleMap 中配置的东西一样，并且导致很多代码感觉它不应该是必要的。我在另一个问题中也提到了同样的计划。

其他想法/想法表示赞赏！

我正在使用采用 OutputStream 的第三方二进制编码器。我从 Marshallable 的 writeMarshallable 方法中检索 OutputStream，类似于：

wire.bytes().outputStream()的实现在每次调用时都会创建一个新的 StreamingOutputStream，这是我希望避免的（当底层 Bytes实际上没有改变时，多余的对象分配）。

也就是说，我正在考虑将 WeakReference 存储到给定的 wire.bytes() 值并检查提供的值引用（即 ==）是否与先前提供的值相同：

所以我的问题是这是否是一种合理的方法，或者你们编年史的人是否有更明智的方法？

谢谢！！

我正在使用 Chronicle Queue v4.5.15。我创建了一个方法来告诉我队列中的元素数量：

我在一夜之间进行了测试，我的组件有一个为 12 月 22 日编写的 cq4 队列文件。它是一个每日周期。我今天尝试将一些元素添加到队列中，但抛出了异常'IllegalStateException: 'file not found' for the upperCycle, file ../path_to_queue/20161314.cq4。

堆栈跟踪：

今天是12月23日，Chronicle为什么还要找档案呢？

这可能与我获得最后一个索引的方式有关吗？

谢谢

这曾经与编年史队列 v3 一起使用。它不会在 v4 中创建队列。我究竟做错了什么？谢谢。

Chronicle ChronicleSignal = ChronicleQueueBuilder.vanilla("somePath").build();

ExcerptAppender appender = ChronicleSignal.createAppender();

我正在尝试使用openHFT/java-runtime-compiler来改进我的变异测试工具，从大量使用磁盘访问到仅使用内存中编译。

在变异测试中，有两种类： A. 变异类，它的定义将不断被操纵/改变和重新编译的类。 B. 其他类，定义不会改变的类，即测试用例类，或者变异类需要的其他类。

通过使用 openHFT/java-runtime-compiler，可以使用下面的代码轻松完成，它是通过为变异类和其他类的每次重新编译创建一个新的类加载器。

这很好用，每次编译 A 类的新定义时，AClass都会适应新定义。

但是，如果顺序颠倒，这将不起作用，就像下面的代码（首先加载BClass然后AClass），有时需要，比如当AClass使用BClass时。类 A 的重新编译，不会适应新的定义，并且将始终使用用于编译类 A 的第一个定义。

我怀疑我需要修改openHFT/java-runtime-compiler 库中的loadFromJava类（代码如下）。我已经尝试省略这些行

我希望每次调用loadFromJava时总是重新编译所有源代码（甚至是已经编译的源代码） 。但它给出了错误的结果。

请帮助我指出使其生效所需的更改。

非常感谢您的帮助。

已编辑

谢谢彼得劳里，我已经尝试过你的建议，但它给出了相同的结果，A 类坚持使用的第一个定义（在第一次迭代中），并且无法更改/使用新定义（在下一次迭代中） .

我收集了症状，可能的解释是第一次迭代（第一次编译/加载类）与下一次迭代有一些不同的处理。从那里我尝试了几件事。

第一个症状

那是当我在 loadFromJava 中放置一个输出行（System.out.println）（下）

输出给出：

在第一次迭代中，它给出了正确的输出，“loadClasses Null”（加载 B 时），因为 loadedClassesMap 没有 classLoader，并给出“clazz Null”（加载 A 时），因为 loadedClassesMap 有 classLoader 但没有t 具有 A 类名。

但是在下一次迭代中，（加载 A 时）它输出“clazz Not Null”，似乎 A 类名已经存储在 loadedClassesMap.get(classLoader) 中，这是不应该发生的。我试图在 CachedCompiler 构造函数中清除加载的ClassesMap。

但它给出了 LinkageError: loader (instance of main/Utama$2): 尝试重复的类定义。

第二个症状

第一次迭代中更强烈的差异症状是当我检查 s_fileManager 缓冲区时。

第一次迭代正如预期的那样，但在下一次迭代中，s_fileManager 缓冲区似乎已经达到了 2 的大小，并且没有重置为 0。

我试图在 CachedCompiler 构造函数（如下）中清除 FileManager 缓冲区，

但它给出了ExceptionInInitializerError。

正如您在上面的示例中所见，ChronicleMap 的行为与 ConcurrentHashMap（与 HashMap 相同）有点不同，因为它无法使用 hashCode 或 equals 查找键。

有人可以指出可以做些什么来解决这个问题吗？

更新; 执行时，程序将返回以下结果：

我对堆外内存的工作方式有点困惑。我有一台具有 32GB 内存的服务器和一个大小约为 1TB 的键值映射数据集。我正在寻找一个简单快速的嵌入式 Java 数据库，它允许我根据这个 1TB 数据集将键映射到一个值，该数据集大部分必须从磁盘读取。该数据集中的每个条目都很小（<500 字节），所以我认为使用文件系统会效率低下。

我想为此使用编年史地图。我读到堆外内存使用可能超过内存大小，并且它以某种方式与文件系统交互，但同时，Chronicle Map 被描述为内存数据库。Chronicle Map 可以为我的服务器处理 1TB 数据集，还是我只能使用 32GB 或更少的数据集？

1）在编年史队列 v4中，大多数测试模式显示某种形式的DocumentContext.isPresent() 繁忙状态检查，当ExcerptTailer位于队列末尾并且代码正在等待新条目到达时ExcerptAppender。

2) 是否有用于异步通知的内置编年史队列机制appender -> tailer，以便在收到通知事件时，tailer保证给定至少有一个条目由 发布appender，准备读取？

3）如果不是，那么推荐的实施模式是什么event listener？请分享一个工作示例？

什么会导致编年史队列出现段错误？我假设我在某处错过了配置。我有一个这样创建的只读编年史队列：

JVM segfaulted 2016-12-31T00:00:00，这是我假设队列文件被循环的时候。这是环境：

编年史队列 4.5.19 JVM OpenJDK 1.8.0_112-b16 Ubuntu 14.04.3 LTS Linux 3.13.0-74

这是堆栈跟踪：

我已经实现了一个简单的 Spring Boot 应用程序，它接收网络消息，使用 appender.writeText(str) 将其排队到 SingleChronicleQueue，另一个线程使用 tailer.readText() 轮询消息。经过一些处理后，处理过的消息被放置在另一个 SingleChronicleQueue 中以发送出去。我在应用程序中有三个队列。

该应用程序每晚都会轮换文件，而第一个奇怪的事情是文件大小（对于每个 Q）是相同的（对于每个 Q 是不同的）。最大的 cq4 文件每天大约 220MB。

我面临的问题是，从开始到现在的三天内，内存从 480MB 增长到 1.6GB，这是不合理的。

我有一个想法，我在配置中遗漏了一些东西，或者我的实现很天真/糟糕。（我不会在每次使用后关闭 appender 和 tailer，应该这样）。

这是一个精简的示例，也许有人可以阐明。