chronicle-map

Using Chronicle Map producing garbage while using Streams API

由 杀马特。学长 韩版系。学妹 提交于 2021-01-28 03:36:02
问题 Today I was experimenting with Chronicle Map. Here is a code sample: package experimental; import net.openhft.chronicle.core.values.IntValue; import net.openhft.chronicle.map.ChronicleMap; import net.openhft.chronicle.values.Values; public class Tmp { public static void main(String[] args) { try (ChronicleMap<IntValue, User> users = ChronicleMap .of(IntValue.class, User.class) .name("users") .entries(100_000_000) .create();) { User user = Values.newHeapInstance(User.class); IntValue id =

IllegalArgumentException when populating a ChronicleMap with high variability in value size

由 徘徊边缘 提交于 2020-01-26 04:16:27
问题 A while back, I asked this question about a ChronicleMap being used as a Map<String,Set<Integer>> . Basically, we have a collection where the average Set<Integer> might be 400, but the max length is 20,000. With ChronicleMap 2, this was causing a rather vicious JVM crash. I moved to ChronicleMap 3.9.1 and have begun to get an exception now (at least it's not a JVM crash): java.lang.IllegalArgumentException: Entry is too large: requires 23045 chucks, 6328 is maximum. at net.openhft.chronicle

ChronicleMap causes JVM to crash when values are highly variable in size

由 谁说我不能喝 提交于 2019-12-12 02:12:58
问题 We've had success so far using ChronicleMap for most things we wanted to use it for, and most data sets have worked just fine. One use case we have is using it as a multimap, covering most of the concerns with doing so. We're using it as a Map<String,Set<Integer>> specifically in this case. However, we've run into some interesting JVM crashes and are having trouble finding a deterministic pattern so we can avoid them. So, before we put all the Set<Integer> into ChronicleMap , we have it

Using ChronicleMap as a key-value database

由 百般思念 提交于 2019-12-11 11:06:45
问题 I would like to use a ChronicleMap as a memory-mapped key-value database ( String to byte[] ). It should be able to hold up to the order of 100 million entries. Reads/gets will happen much more frequently than writes/puts, with an expected write rate of less than 10 entries/sec. While the keys would be similar in length, the length of the value could vary strongly: it could be anything from a few bytes up to tens of Mbs. Yet, the majority of values will have a length between 500 to 1000 bytes

Multimaps in ChronicleMap

由 拥有回忆 提交于 2019-12-03 13:56:52
问题 There is definitely a disclaimer on ChronicleMap's GitHub about Multimaps in ChronicleMap: Chronicle Map is not... ... No secondary indexes. A multimap. Using a ChronicleMap<K, Collection<V>> as multimap is technically possible, but often leads to problems... Unfortunately, this is one of my use cases and using off-heap storage for that (with ChronicleMap) would certainly be the easiest route to do so. Let me try to explain my problem with pizzas. I have 100,000 different pizzas. Each pizza

Multimaps in ChronicleMap

由 时光总嘲笑我的痴心妄想 提交于 2019-12-03 03:10:36
There is definitely a disclaimer on ChronicleMap's GitHub about Multimaps in ChronicleMap: Chronicle Map is not... ... No secondary indexes. A multimap. Using a ChronicleMap<K, Collection<V>> as multimap is technically possible, but often leads to problems... Unfortunately, this is one of my use cases and using off-heap storage for that (with ChronicleMap) would certainly be the easiest route to do so. Let me try to explain my problem with pizzas. I have 100,000 different pizzas. Each pizza has an ID and lots of different toppings and crusts. I have three access patterns: Give me the pizza by
订阅 chronicle-map