[erlang-questions] [ANN] CloudI 1.2.2 Released!

Michael Truog <>
Sun Jun 2 06:19:36 CEST 2013


Download 1.2.2 from http://sourceforge.net/projects/cloudi/files/latest/download

What is CloudI?
A Cloud at the lowest level!

CloudI (http://cloudi.org) is a "universal integrator" using an Erlang core, with its actor model, to pursue efficiency, fault-tolerance and scalability.  The CloudI API provides a minimal interface to communicate among actors that are called services, so programming language agnostic, database agnostic, and messaging bus agnostic integration can occur.  CloudI currently integrates with the programming languages Erlang, C/C++, Java, Python, and Ruby, the databases PostgreSQL, MySQL, couchdb, memcached, and tokyotyrant, the messaging bus ZeroMQ and the internal CloudI service bus.  HTTP is also supported for easy integration with cowboy.  If anyone is willing to get involved, don't hesitate to contact me or start looking at the code.  Thank you for all the suggestions and questions so far!

This release finished up some performance issues based on loadtesting and profiling.  The latest loadtest results are summarized at https://github.com/okeuday/CloudI/raw/master/src/tests/http_req/loadtest/results_v1_2_2/201306_summary.pdf .  Please note that the 1.2.2 release only currently works with R16 (a problem with the old reltool prevents R15 usage right now), tell me if that is a problem.  The gory details are below:

  * Performance was improved further for external services with the addition
    of UNIX domain socket support as the "local" protocol.  The python_c
    CloudI API now has minimal latency.  The Erlang, C/C++, and Java CloudI
    APIs now have similarly low latency (20-40ms latency mean max,
    130-170ms latency max sample, for 20k connections at 10k req/s with the
    "local" protocol).  Now all the CloudI API implementations have been
    modified to send the request response before an exception is thrown to
    avoid imposing any extra request latency.
  * v1 UUIDs now have the correct variant bits set.  This fix makes the UUIDs
    backwards incompatible (if older UUIDs have been stored in a database).
  * Prevously, external service buffer sizes where assigned after being doubled.
    Now, that is no longer the case.  If that is a concern, make sure to double
    your configured buffer size (specified in the external service
    configuration).
  * Problems with the CloudI database services have now been fixed.  It is now
    true that the cloudi_service_init/3 self() process is the Dispatcher
    Erlang process used in future service function calls.  That will remain
    true in the future to maintain consistency with OTP behaviours.
    However, it is mainly for proper link/monitor creation, it is still
    best to use cloudi_service:self/1 when retrieving the service's Erlang
    process.
  * Added the "cloudi" module for Erlang usage of CloudI services within
    external Erlang processes.
  * Added the "cloudi_x_" scope (i.e., namespace) prefix to all external
    CloudI dependencies so that it is easier to include CloudI with other
    Erlang applications.  This change will impact any Erlang applications
    that currently use CloudI and CloudI external dependencies, but have not
    yet included their own version of the external dependencies.
  * Added proper support for loading Erlang applications and Erlang releases
    that include a CloudI service module.
  * Added newest/oldest destination refresh method options.
  * Now external service configuration can use the "default" atom for either
    the protocol and/or the buffer size.  The default protocol is the new
    "local" protocol and the default buffer size is currently 16384 bytes
    (Linux localhost (inet) MTU) but may change in the future based on
    further testing.

Please mention any problems, issues, or ideas!

Thanks,
Michael

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130601/4f09fb88/attachment.html>


More information about the erlang-questions mailing list