chronicle | 易学教程

Using Chronicle Map producing garbage while using Streams API

阅读更多关于 Using Chronicle Map producing garbage while using Streams API

问题 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 =

网络安全在后疫情时代的10个变化

阅读更多关于网络安全在后疫情时代的10个变化

云栖号资讯：【点击查看更多行业资讯】在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！如今，一些首席信息安全官表示，冠状病毒疫情正在破坏其网络安全计划并改变其优先级。虽然没人知道冠状病毒疫情的影响何时会结束，但对于这种新常态需要有清醒的认识。以下是行业专家对网络安全在后疫情时代的10个改变进行的预测： 1. 在家工作(WFH)成为默认模式这是一个显而易见的假设，但可以提供数据来证明。根据ESG公司的研究，79%的IT高管表示，在冠状病毒疫情结束之后，他们所在的组织将实施更加灵活的在家工作策略。此外，在家工作策略似乎运行良好：78%的在家远程工作的人员表示在家工作更具生产力或生产力并没有减弱。在提高生产力和节省房地产成本方面，企业的员工在家工作显然成为一个良好的选择，并且正在推动安全投资和优先事项出现更多变化。 2. 网络安全边界将会消亡由多家金融服务机构20年前成立的一个名为Jericho的论坛提出了取消网络边界的理念。尽管大多数安全专家都认同这一想法，但网络边界的安全性仍然是一个挑战，因此网络边界仍然存在，并且随着时间的推移而变化缓慢。冠状病毒疫情可能最终打破网络安全边界。为了支持更分散的IT基础设施，安全控制措施将大量地移至网络端点(用户、设备、应用程序、数据等)。好消息是，基于云计算的管理平台将使该架构比过去更易于扩展和操作。那么什么是新的边界?用户

Reading byte[] chronicle queue

阅读更多关于 Reading byte[] chronicle queue

来源： https://stackoverflow.com/questions/48271644/reading-byte-chronicle-queue

Regarding sub-topics in chronicle queue

阅读更多关于 Regarding sub-topics in chronicle queue

问题 I'm looking to write messages to a single queue. I'd like to use the sub-topics functionality, so that tailers can pick and choose either to read all of the sub-topics under one topic, or pick specific sub-topics to read from. The documentation mentions that sub-topics are supported in a directory under the main topic, so in order to read from a subtopic, do we just create a new queue and point it to the sub-topic path? SingleChronicleQueue queue = SingleChronicleQueueBuilder.binary("Topic")

Chronicle Consumer not reading records correctly?

阅读更多关于 Chronicle Consumer not reading records correctly?

问题 I am using chronicle-queue (5.16.13) to write and read json values to a chronicle file. To write objects I use the following in a loop try (final DocumentContext dc = appender.writingDocument()) { dc.wire().write(() -> "msg").text("Hallo asdf"); System.out.println("your data was store to index="+ dc.index()); return true; } catch (Exception e) { logger.warn("Unable to store value to chronicle", e); return false; } and to read items I do the following call in a loop DocumentContext

IllegalArgumentException when populating a ChronicleMap with high variability in value size

阅读更多关于 IllegalArgumentException when populating a ChronicleMap with high variability in value size

问题 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

堆内内存与堆外内存

阅读更多关于堆内内存与堆外内存

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 堆外内存一直是Java业务开发人员难以企及的隐藏领域，究竟他是干什么的，以及如何更好的使用呢？那就请跟着我进入这个世界吧。一、什么是堆外内存 1、堆内内存（on-heap memory）回顾堆外内存和堆内内存是相对的二个概念，其中堆内内存是我们平常工作中接触比较多的，我们在jvm参数中只要使用-Xms，-Xmx等参数就可以设置堆的大小和最大值，理解jvm的堆还需要知道下面这个公式：堆内内存 = 新生代+老年代+持久代如下面的图所示： Paste_Image.png 在使用堆内内存（on-heap memory）的时候，完全遵守JVM虚拟机的内存管理机制，采用垃圾回收器（GC）统一进行内存管理，GC会在某些特定的时间点进行一次彻底回收，也就是Full GC，GC会对所有分配的堆内内存进行扫描，在这个过程中会对JAVA应用程序的性能造成一定影响，还可能会产生Stop The World。常见的垃圾回收算法主要有：引用计数器法（Reference Counting）标记清除法（Mark-Sweep）复制算法（Coping）标记压缩法（Mark-Compact）分代算法（Generational Collecting）分区算法（Region）注：在这里我们不对各个算法进行深入介绍

Reading message from chronicle queue does not move the current index to the next cycle automatically

阅读更多关于 Reading message from chronicle queue does not move the current index to the next cycle automatically

问题 Reading message from chronicle queue does not move the current index to the next cycle automatically. I get the following logs messages: 697917 [SCHEDULER#4] INFO net.openhft.chronicle.queue.impl.single.SingleChronicleQueueExcerpts - Rolled 2 times to find the next cycle file. This can occur if you appenders have not written anything for a while, leaving the cycle files with a gap. What does this means? My queue files are : 20160824.cq4 20160826.cq4 20160829.cq4 20160830.cq4. The 20160825.cq4

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

阅读更多关于 ChronicleMap causes JVM to crash when values are highly variable in size

问题 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

阅读更多关于 Using ChronicleMap as a key-value database

问题 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