Previous releases of WSO2 Message Broker was tightly coupled with Apache Cassandra database. We ideally made that choice to make MB faster as Cassandra's writing speed is fast, and also Cassandra can be scaled in distributed manner.
That architecture was suitable for customers who had large messaging requirements. To address small scale messaging needs essentially there is no point of having such a scaled system. Tuning Cassandra to work properly is somewhat tricky as well. Thus we took the decision to make the store of MB abstract that any store is pluggable.
WSO2 Message Broker runs on Carbon. Carbon already had the store abstraction. You can configure your dataSource and its properties and tell server to use that config via JNDI. We used the same concept for MB.
When we are about to release Milestone 1 we have support for
- MySQL
- MSSQL
- Apache Cassandra
- H2 File system based store
Interestingly, to make the balance between performance and reliability (a natural low), we introduced two modes to store messages
- Async - we buffer and store (degree of buffering is configurable). This gives higher performance.
- Direct - we store messages as soon as they come into the server without buffering. This gives higher reliability.
With MB 3.0.0 you can expect following new features and enhancements.
- No need of 9 JVMs to make a broker cluster. If your enterprise already has tolerable JDBC store minimum num of nodes for a broker cluster is 2 !
- MQTT ( Message Queue Telemetry Transport) support, which is a light weight transport.
- Much more stability
- Less memory consumption
- New message distribution algorithm for distributed subscribers over the cluster.
- Better performance even with JDBC stores (if not satisfied, just scale !!).
- Error, warning reporting improvements on console
- Hybrid store model - Cassandra for Message store and MqSQL for Control information store is possible
No comments:
Post a Comment