Ultra-low-latency, batching and concurrent queue for IPC in Java
1–10 of 76 posts
Re: Ultra-low-latency, batching and concurrent queue for IPC in Java
#2Weird to see this here! I've used CoralBlocks in the low-latency trading domain previously. Highly recommend. The API is kind, they're very responsive, and the latency is exceptional (and comes with all the basics like thread pinning built-in for convenience)
Re: Ultra-low-latency, batching and concurrent queue for IPC in Java
#3Weird to see this here! I've used CoralBlocks in the low-latency trading domain previously. Highly recommend. The API is kind, they're very responsive, and the latency is exceptional (and comes with all the basics like thread pinning built-in for convenience)
How does it compare to LMAX Disruptor if you have any experience with both?
Re: Ultra-low-latency, batching and concurrent queue for IPC in Java
#4This is fascinating. I have no idea what something like this would be used for though... what are the use cases?
Re: Ultra-low-latency, batching and concurrent queue for IPC in Java
#5Weird to see this here! I've used CoralBlocks in the low-latency trading domain previously. Highly recommend. The API is kind, they're very responsive, and the latency is exceptional (and comes with all the basics like thread pinning built-in for convenience)
> CoralBlocks in the low-latency trading domain previously.
Yeah, modern JVM is a true miracle and you can be x5 productive (and safe!) compared to C/C++
Do you have any recommendations for a low latency work queue (with in a jvm)?
I want to spawn millions of micro-second-tasks per second, to worker cores..
I am on a massive cache CPU so memory latency hasnt raised its ugly head yet
EDIT: not LMAX please...
Re: Ultra-low-latency, batching and concurrent queue for IPC in Java
#6This is fascinating. I have no idea what something like this would be used for though... what are the use cases?
Basically if you want to schedule workers on a separate JVM, but don't want to pay the latency cost of something like a DB-backed queue or a library with some FFI component.
Re: Ultra-low-latency, batching and concurrent queue for IPC in Java
#7Weird to see this here! I've used CoralBlocks in the low-latency trading domain previously. Highly recommend. The API is kind, they're very responsive, and the latency is exceptional (and comes with all the basics like thread pinning built-in for convenience)
Given the documentation says that this is supposedly to be between JVMs, how do they handle the serialize/deserialize?
Re: Ultra-low-latency, batching and concurrent queue for IPC in Java
#8Our kafka isn’t reliable enough. I need to write data on disk before flushing it to kafka. Can I use this lis to write data to disk and then consume inside same jvm. I need data to live through restarts
Re: Ultra-low-latency, batching and concurrent queue for IPC in Java
#9Our kafka isn’t reliable enough. I need to write data on disk before flushing it to kafka. Can I use this lis to write data to disk and then consume inside same jvm. I need data to live through restarts
Can you explain what your issue is with Kafka? What makes it not reliable enough?
Re: Ultra-low-latency, batching and concurrent queue for IPC in Java
#10Weird to see this here! I've used CoralBlocks in the low-latency trading domain previously. Highly recommend. The API is kind, they're very responsive, and the latency is exceptional (and comes with all the basics like thread pinning built-in for convenience)
Given the documentation says that this is supposedly to be between JVMs, how do they handle the serialize/deserialize?
They punt on the actual serialization format: https://www.coralblocks.com/index.php/inter-process-communic...
In most applications like this you'll see direct byte manipulation to byte buffers because you want to pull as much performance as possible.
There are fast serialization formats like SBE that people leverage for this as well.