Mappedbus review

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Mappedbus review

mikael

Hi,

I'm working on a library for efficient IPC between multiple Java processes/JVMs and I'm wondering if anyone could help me review the design and implementation for any potential issues?

The implementation is quite simple and short, less than 200 lines of code excluding comments, and available here:
http://github.com/caplogic/Mappedbus/tree/master/src/main/io/mappedbus

Quick summary of what the library does:
- Mappedbus is a Java based high throughput, low latency message bus, using either a memory mapped file or shared memory as transport
- Mappedbus was inspired by Java Chronicle with the main difference that it's designed to efficiently support multiple writers – enabling use cases where the order of messages produced by multiple processes are important
- Mappedbus can also be described as an efficient IPC mechanism which enable several Java processes/JVMs to communicate by message passing.
- The throughput (on a laptop, i7-4558U @ 2.8 GHz) between a single producer writing at full speed and a single consumer is around 40 million messages per second (a small message consisting of three integer fields)

Here's how the library solves the synchronization problem between multiple writers (each running in it's own process/JVM):
- The first eight bytes of the file make up a field called the limit. This field specifies how much data has actually been written to the file. The readers will poll the limit field (using volatile) to see whether there's a new record to be read.
- When a writer wants to add a record to the file it will use the fetch-and-add instruction to atomically update the limit field.
- When the limit field has increased a reader will know there's new data to be read, but the writer which updated the limit field might not yet have written any data in the record. To avoid this problem each record contains an initial byte which make up the commit field.
- When a writer has finished writing a record it will set the commit field (using volatile) and the reader will only start reading a record once it has seen that the commit field has been set.
- A writer might crash after it has updated the limit field but before it has updated the commit field. To avoid this problem there's a field next to the commit field called the rollback field. The reader has a timeout for how long it will wait for the commit field to be set. When that time is reached the reader will set the rollback field (using volatile) and continue with the next record. The rollback field has precedence over the commit field, when the rollback field is set the record is always ignored by the readers.

The solution seems to work well on Linux x86 with Oracle's JVM (1.8) but I understand it won't work on all platforms (and it's not intended to).

I'd simply like to make sure the solution is sound so any ideas on potential issues would be very much appreciated.

Regards,

Mikael

 

 

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Mappedbus review

corporate.piyush

One way to evaluate it is to compare it with other existing libs e.g. combination of Hazelcast and MapDB 2.0.

There are numerous amount of use cases and failures, failure report scenario you need to keep in mind. Needless to say some kind of administration console would be needed if we you are targeting enterprise world

Thanks,
Piyush Katariya

On May 30, 2015 10:19 PM, <[hidden email]> wrote:

Hi,

I'm working on a library for efficient IPC between multiple Java processes/JVMs and I'm wondering if anyone could help me review the design and implementation for any potential issues?

The implementation is quite simple and short, less than 200 lines of code excluding comments, and available here:
http://github.com/caplogic/Mappedbus/tree/master/src/main/io/mappedbus

Quick summary of what the library does:
- Mappedbus is a Java based high throughput, low latency message bus, using either a memory mapped file or shared memory as transport
- Mappedbus was inspired by Java Chronicle with the main difference that it's designed to efficiently support multiple writers – enabling use cases where the order of messages produced by multiple processes are important
- Mappedbus can also be described as an efficient IPC mechanism which enable several Java processes/JVMs to communicate by message passing.
- The throughput (on a laptop, i7-4558U @ 2.8 GHz) between a single producer writing at full speed and a single consumer is around 40 million messages per second (a small message consisting of three integer fields)

Here's how the library solves the synchronization problem between multiple writers (each running in it's own process/JVM):
- The first eight bytes of the file make up a field called the limit. This field specifies how much data has actually been written to the file. The readers will poll the limit field (using volatile) to see whether there's a new record to be read.
- When a writer wants to add a record to the file it will use the fetch-and-add instruction to atomically update the limit field.
- When the limit field has increased a reader will know there's new data to be read, but the writer which updated the limit field might not yet have written any data in the record. To avoid this problem each record contains an initial byte which make up the commit field.
- When a writer has finished writing a record it will set the commit field (using volatile) and the reader will only start reading a record once it has seen that the commit field has been set.
- A writer might crash after it has updated the limit field but before it has updated the commit field. To avoid this problem there's a field next to the commit field called the rollback field. The reader has a timeout for how long it will wait for the commit field to be set. When that time is reached the reader will set the rollback field (using volatile) and continue with the next record. The rollback field has precedence over the commit field, when the rollback field is set the record is always ignored by the readers.

The solution seems to work well on Linux x86 with Oracle's JVM (1.8) but I understand it won't work on all platforms (and it's not intended to).

I'd simply like to make sure the solution is sound so any ideas on potential issues would be very much appreciated.

Regards,

Mikael

 

 

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest