问题标签 [chronicle]

ChronicleMap 理论上最多可以包含多少个条目？可以放入 ChronicleMap 的最大条目数是多少？

我正在编写一个适配器以在 Apache Aries 远程服务管理中使用编年史队列。当我只使用一个线程时它工作正常。使用多个线程时，我会遇到如下异常。

知道我做错了什么吗？

作为参考，这是我的代码： https ://github.com/cschneider/rsa-chronicle-provider/blob/master/src/test/java/org/apache/aries/rsa/provider/chronicle/ChronicleProviderTest.java

如果您增加执行程序中的线程数，您可以看到异常。

我们正在使用 ChronicleMap 来支持大量不同存储中的堆外持久性，但在最简单的用例中遇到了一些问题。

首先，这是我为使创建更容易而编写的助手：

它使用https://github.com/phatak-dev/java-sizeof进行对象大小估计。这是我们想要支持的用法：

但它抛出了一个异常：

[错误] 线程“主”java.lang.ClassCastException 中的异常：键必须是 int，但在 net.openhft.chronicle.hash.impl.VanillaChronicleHash.checkKey(VanillaChronicleHash.java) 是类 java.lang.Integer [错误] :661) [错误] 在 net.openhft.chronicle.map.VanillaChronicleMap.queryContext(VanillaChronicleMap.java:281) [错误] 在 net.openhft.chronicle.map.VanillaChronicleMap.put(VanillaChronicleMap.java:390) [错误]在 ...

我可以看到它可能与 Scala 的 Int 的原子性有关，而不是 Java 的 Integer，但我该如何绕过呢？

斯卡拉 2.11.7

编年史地图 3.8.0

ChronicleMap 的 GitHub 上肯定有关于ChronicleMap 中的Multimaps 的免责声明：

纪事地图不是...

...没有二级索引。

多图。使用ChronicleMap<K, Collection<V>>as multimap 在技术上是可行的，但通常会导致问题......

不幸的是，这是我的用例之一，为此使用堆外存储（使用 ChronicleMap）肯定是最简单的方法。

让我试着解释一下我对披萨的问题。我有 100,000 种不同的比萨饼。每个比萨饼都有一个 ID 和许多不同的配料和外壳。我有三种访问模式：

• 按 ID 给我披萨。
• 给我所有有特殊配料的比萨饼。
• 给我所有有特殊外壳的比萨饼。

我可以使用ChronicleMap<UUID,Pizza>. 但这只是一种访问模式。我不想遍历每个比萨饼来找到具有匹配顶部或外壳的比萨饼。所以，我想存储类似ChronicleMap<Topping,Collection<UUID>>and的东西ChronicleMap<Crust,Collection<UUID>>。

然后，如果有人问我所有的意大利辣香肠披萨，我会在顶部的 ChronicleMap 中查找匹配披萨的 UUID，然后在主披萨地图中查找。

但是上面引用的文档让我害怕。有谁知道这样的事情经常导致的这些“问题”可能是什么？为什么我不应该这样做，即使它似乎对我有用？它与 ChronicleMap 如何存储序列化对象，特别是集合有关吗？

针对潜在问题的一些附加说明：

1. 我们稍后可能会添加需要更新集合的比萨饼。
2. 许多进程都在尝试执行这些操作，因此需要通过 ChronicleMap 共享地图，而不仅仅是基本的 ConcurrentMap。

假设我有类似的东西：

在这种情况下，因为 long[] 看起来我不能使用

（我得到field type class [Lnet.openhft.chronicle.core.values.LongValue; is not supported: not a primitive, enum, CharSequence or another value interface例外）

听起来很奇怪我错过了什么？处理此类对象的最佳方法是什么？实现自己的序列化？

如果我错了，请纠正我，但是如果我尝试在同一个项目中使用 Map3 和 Engine 由于相同的包名称，我会遇到麻烦吗？有什么办法可以做到吗？

PS旁注-由于依赖性问题，现在无法编译引擎主分支（至少是“演示”模块）？

到目前为止，我们已经成功地使用ChronicleMap了我们想要使用它的大多数东西，并且大多数数据集都工作得很好。我们的一个用例是将它用作多图，涵盖了这样做的大部分问题。Map<String,Set<Integer>>在这种情况下，我们专门使用它。但是，我们遇到了一些有趣的 JVM 崩溃，并且难以找到确定性模式，因此我们可以避免它们。

因此，在我们将所有内容Set<Integer>放入之前ChronicleMap，我们将其完全放在 JVM 中，因此我们立即编写以减少碎片。由于我们将它完全保存在内存中，我们可以确定最大和平均Set<Integer>大小是多少，并且可以轻松ChronicleMap地使用ChronicleMapBuilder.averageValueSize. 在大多数情况下，这工作得很好。

然而，在某些情况下，当 JVM 的大小Set<Integer>偏离平均值时，JVM 会崩溃。例如，平均大小可能是 400，但我们可以有包含 20,000 个整数的异常值集。我们仍然可以使用一组 400 个整数的平均序列化大小来调整地图的大小，并且它开始填充ChronicleMap得很好，直到它达到一个非常大的列表。

所以问题是：我如何计算出我可以偏离平均值有多大？我希望平均值确实是一个平均值，但似乎有一些最大值高于该值会导致 JVM 死机。

我们设计了一种算法将大集合拆分成更小的集合（例如，如果密钥是 AAA，那么现在有密钥 AAA:1、AAA:2、... AAA:n）。拆分集的大小是平均大小的 10 倍。换句话说，如果平均大小是 500，但我们有一个 20,000 的集合，我们会将其分成四个 5,000 (500 * 10) 的元素集合。

这在大多数情况下都有效，但随后我们遇到了另一个奇怪的案例，即使这种拆分也不够。我将因子减小到平均大小的 5 倍，现在它又可以工作了……但我怎么知道它足够小？我认为知道源问题或如何确定导致它的确切原因是最好的方法，但唉，我不知道为什么ChronicleMap在这里挣扎。

另外，FWIW，我使用的是旧版本 2.1.17。如果这是在较新版本中修复的错误，我想知道有关该错误的一些详细信息，以及我们是否可以通过自己的方式避免它（例如拆分集合）但仍继续使用 2.1.17（我们稍后会升级；只是不想再摇摆不定）。

我们正在尝试将 Chronicle HFT 作为低延迟消息传递 b/w 组件的概念证明。我们正在使用chronicle-1.7.2.jar

我们有一个读者和作家，作家一直在为编年史写摘录，而读者则在忙碌的 while 循环中继续阅读。

当编年史文件中有可用数据时，我们无法在 epoll 上挂钩 reader 并使其可选择。通常我们在 DatagramChannel 数据可用性上进行选择。

请阐明如何使阅读器可选择并在编年史上写入数据时注册回调。

我期待将 Chronicle Map 用作数据存储/数据缓存，并打算与在同一机器上运行的其他 JVM 进程共享它，以减少每个其他 JVM 进程的内存占用，否则每个 JVM 进程将加载相同的数据。每当从数据存储中添加或删除条目时，是否可以获得有关每个 JVM 进程的通知？它真的会减少内存占用吗？因为，每个 JVM 进程无论如何都会创建一些域对象。

我查看了 API 和文档，但我不太清楚如何实现我的用例。MapMethods 和 remoteOperations 最接近它，也许是要走的路。我想知道获得预期功能的正确方法是什么，或者我是否有路要走。

如果我走在正确的轨道上，那么我猜测 mapMethods/remoteOperations 只需要在观察者端提供，而不是在主数据存储上。我对么？

我真的对chronicle的连接界面感到困惑。我找不到任何关于它的测试代码或源代码。

我想捕捉断开和连接事件。

我的设置看起来像（香草编年史 3.6.2。）；

两个相同的过程，相互连接。

资源：：

裁缝::