问题标签 [chronicle-map]

我在我的机器上使用 Java 1.7 中的 Chronicle Map。我想知道我可以在 java 1.6 上使用它吗？因为我必须在 Java 1.6 上运行的服务器上构建和部署它

我有一个ChronicleMap（v2.3.2）在服务器中运行，使用以下调用创建：

存储在遗嘱中的条目数量有可能ChronicleMap需要发展。因此，我设想在应用程序启动时执行以下操作：

1. ChronicleMap从磁盘加载现有的
2. 从现有的条目中获取最大数量ChronicleMap
3. 如果新大小（从配置文件加载）没有不同，则完成，否则...
4. ChronicleMap用新尺寸创建一个新的
5. 将旧的内容复制ChronicleMap到新的
6. 关闭并删除旧的ChronicleMap

但是，我在 ChronicleMap 公开的界面中看不到任何内容，这将使我找出在entries创建方法时传递给该方法的值。我假设这longSize()只是实际存储的条目数，而不是地图的最大大小。

有没有办法找出这个值？或者也许有更好的方法来进行这种迁移？

我在使用 Gradle 构建并使用 AspectJ 的应用程序中遇到了以下异常。该应用程序在 Eclipse 中启动时运行良好，但在使用 Gradle 构建后无法启动：

在我的 build.gradle 我有：

我也尝试过使用早期版本，但没有成功。

从 Eclipse 开始时我注意到的一件事是，当第一次访问 Chronicle 时会出现这个新警告：

但我不确定这是否相关。我是否缺少其他依赖项？

编辑：我还应该提到我使用 Spring，并且我的 Chronicle 地图被实例化为 Spring bean 的一部分。

编辑 2：调试日志没有产生任何有用的东西。接下来我将尝试降级到旧版本的编年史地图。

编辑3：它在构建时有效

编辑 4：与新的 3.6.0-rc 相同的错误

编辑5：我有

在我的 build.gradle 中添加 tools.jar（Gradle 没有提供 afaik）。它也是我开始生成的（胖）jar 文件的一部分。

真的是一个简单的问题：我看到编年史 Map 3X 正在将一些功能转移到引擎产品中。然而，引擎本身依赖于 Map 2X。我有点困惑如何将它们一起使用？我想我错过了一些东西，但不确定到底是什么。

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

我们正在使用 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（我们稍后会升级；只是不想再摇摆不定）。