- OpenDaylight - AKKA 2.6.x

[OpenDaylight] Migrating to AKKA 2.6.X has enabled OpenDaylight to migrate to the current version of AKKA, 2.6.x. Today, we will review recent changes to AKKA, which is the heart of OpenDaylight’s Clustering functionality.

As the largest committer to the OpenDaylight source-code, will regularly keep you updated and posted about our efforts in projects surrounding OpenDaylight.

Released in November 2019, added many improvements, including better documentation, and introduced a lot of new features. In case you are new to AKKA, here is a description from the official website:

[It is] a set of open-source libraries for designing scalable, resilient systems that span processor cores and networks. [AKKA] allows you to focus on meeting business needs instead of writing low-level code to provide reliable behavior, fault tolerance, and high performance.

OpenDaylight Migrates to AKKA 2.6

The most important features of AKKA 2.6 are shortly described below; for the full list, please see the release notes.

Make sure to check out the AKKA Migration Guide 2.5.x to 2.6.xand the OpenDaylight page!

AKKA Typed

AKKA Typed is the new typed Actor API. It was declared ready for production use since AKKA 2.5.22, and since 2.6.0 it’s the officially recommended Actor API for new projects. Also, the documentation was significantly improved.

In a typed API, each actor declares an acceptable message type, and only messages of this type can be sent to the actor. This is enforced by the system.
For untyped extensions, seamless access is allowed.

The classic APIs for modules, such as Persistence, Cluster Sharding and Distributed Data, are still fully supported, so the existing applications can continue to use those.


Artery is a reimplementation of the old remoting module, aimed at improving performance and stability, based on Aeron (UDP) and AKKA Streams TCP/TLS, instead of Netty TCP.

Artery provides more stability and better performance for systems using AKKA Cluster. Classic remoting is deprecated but still can be used. More information is provided in the migration guide.

Jackson-Based Serialization

AKKA 2.6 includes a new Jackson-based serializer, supporting both JSON and CBOR formats. This is the recommended serializer for applications using AKKA 2.6. Java serialization is disabled by default.

Distributed Publish-Subscribe

With AKKA Typed, actors on any node in the cluster can subscribe to specific topics. The message published to one of these topics will be delivered to all subscribed actors. This feature also works in a non-cluster setting.

Passivation in Cluster

With the Cluster passivation feature, you may stop persistent entities that are not used to reduce memory consumption by defining a timeout for message receiving. Passivation timeout can be pre-configured in cluster settings or set explicitly for an entity.

Cluster: External shard allocation

A possibility to use a new alternative external shard allocation strategy is provided, which allows explicit control over the allocation of shards. This covers use cases such as Kafka Partition consumption matching with shard locations to avoid network hops.

Sharded Daemon Process

Sharded Daemon Process allows specific actors in a cluster, to keep it alive and balanced. For rebalancing, an actor can be stopped and then started on a new node. This feature can be useful in case the data processing workload needs to be split across a set number of workers.

by Konstantin Blagov | Leave us your feedback on this post!

You can contact us at

Explore our Pantheon GitHub.

Watch our YouTube Channel.

Karaf in OpenDaylight

[Thoughts] On Karaf & Its Future

These thoughts were originally sent on the public karaf-dev mailing list, where Robert Varga wrote a compelling opinion on what the future holds for Karaf and where its currently is headed. The text below was slightly edited from the original.

With my various OpenDaylight hats on, let me summarize our project-wide view, with a history going back to the project that was officially announced (early 2013).

From the get-go, our architectural requirement for OpenDaylight was OSGi compatibility. This means every single production (not maven-plugin obviously) artifact has to be a proper bundle.

This highly-technical and implementation-specific requirement was set down because of two things:

  1. What OSGi brings to MANIFEST.MF in terms of headers and intended wiring, incl. Private-Package
  2. Typical OSGi implementation (we inherited Equinox and are still using it) uses multiple class loaders and utterly breaks on split packages

This serves as an architectural requirement that translates to an unbreakable design requirement of how the code must be structured.

We started up with a home-brew OSGi container. We quickly replaced it for Karaf 3.0.x (6?), massively enjoying it being properly integrated, with shell, management, and all that. Also, feature:install.

At the end of the day, though, OpenDaylight is a toolkit of a bunch of components that you throw together and they work.

Our initial thinking was far removed from the current world of containers when operations go. The deployment was envisioned more like an NMS with a dedicated admin team (to paint a picture), providing a flexible platform.

The world has changed a lot, and the focus nowadays is on containers providing a single, hard-wired use-case.

We now provide out-of-the-box use-case wiring. using both dynamic Karaf and Guice (at least for one use case). We have an external project which shows the same can be done with pure Java, Spring Boot, and Quarkus.

We now also require Java 11, hence we have JPMS – and it can fulfill our architectural requirement just as well as OSGi. Thanks to OSGi, we have zero split packages.

We do not expect to ditch Karaf anytime soon, but rather leverage static-framework for a light-weight OSGi environment, as that is clearly the best option for us short-to-medium term, and definitely something we will continue supporting for the foreseeable future.

The shift to nimble single-purpose wirings is not going away and hence we will be expanding there anyway.

To achieve that, we will not be looking for a framework-of-frameworks, we will do that through native integration ourselves.

If Karaf can do the same, i.e. have its general-purpose pieces available as components, easily thrown together with @Singletons or @Components, with multiple frameworks, as well as nicely jlinkable – now that would be something. 

[OpenDaylight] Sodium: A Developers Perspective

by Robert Varga | Leave us your feedback on this post! continued to be the leader in terms of contributions to the OpenDaylight codebase. While our focus remained on the core platform, we also dabbled into individual plugins to deliver significant performance, scalability and correctness improvements. We are therefore glad to be a significant part of the effort that went into the newest release of OpenDaylight – Sodium.

In Sodium, we have successfully transitioned OpenDaylight codebase to require Java 11 – an effort we have been spearheading since the mid-Neon timeframe. This allows our users to not only reap the runtime improvements of Java 11 (which was possible to do with Sodium), but it allows OpenDaylight code to take advantage of features available in Java 11.

Our continued stewardship of YANG Tools has seen us deliver multiple improvements and new features, most notable of which are:

YANG Parser: has been extended to support Errata 5617 leaf-ref path expressions, which violate RFC7950, but are used by various models seen in the wild — such as ETSI NFV models. YANG parser has also received some improvements in areas of CPU and memory usage when faced with large models, ranging from 10 to 25%, depending on the models and features used.

In-memory Data Tree: the technology underlying most datastore implementations. It has been improved in multiple areas, yielding an overall memory footprint reduction of 30%. This allows better out-of-the-box scalability.

Adoption of Java 11: Java has allowed to deploy improvements to MD-SAL Binding runtime, resulting in measurably faster dispatch of methods across the system, providing benefits to all OpenDaylight plugin code.

We have also continued improvements in the Distributed Datastore. We achieved further improvements to the persistence format, reducing in-memory & on-disk footprint by as much as 25%.

Last but not least, we have taken a hard look at the OVSDB project and provided major refactors of the codebase. This has immensely improved its ability to scale the number of connected devices, as well as individual connection throughput.

If you would like a custom OpenDaylight integration, feel free to contact us!

OpenDaylight Neon logo

[Comparison] OpenDaylight Neon SR1 vs. SR2

The development of OpenDaylight Sodium is already producing significant improvements, some of which are finding their way to the upcoming Service Release of Neon.

These are the test results for OpenDaylight Neon SR2. We have recorded significant improvements in the following areas:

  • Datastore snapshot-size: ~49% reduction
  • Processing time: ~58% reduction
  • In-memory size: ~25% reduction
  • Object count: ~25% reduction
  • NodeIdentifier: ~99.9% reduction
  • AugmentationIdentifier: ~99.9% reduction

These enhancements will also be present in the future, long-awaited release of Sodium.

Our commitment – more commits’s CTO, Robert Varga, is currently the top-single committer to OpenDaylights source-code, according to recent reports. also resides as the number 1 contributor to its source-code.

Bitergia, a software development analytics company, regularly tracks the number of commits to OpenDaylight – based on single commiters and companies. OpenDaylight plays a significant role in’s offerings and solutions.

Apart from’s position as a top contributing organization to ODL, has always been a strong supporter of the open-source community. This support covers a wide range of developers from local, private open-source development groups to international open-source platforms – such as ONAP, OPNFV or

What is OpenDaylight?

OpenDaylight is a collaborative, open-source project, established in 2013. It aims to speed up the adoption of SDN and create a solid foundation for Network Functions Virtualization.

It was founded by global industry leaders, such as Cisco, Ericsson, Intel, IBM, Dell, HP, Red Hat, Microsoft, and open to all.’s involvement in OpenDaylight goes way back to its beginnings. We have led the way in what an SDN controller is and should aspire to be. This requires dedication, which was proven over the years with an extensive amount of contribution and a successful track record, thanks to our expert developers.

Contact us, if you are interested in our solutions, which are based on, or integrate OpenDaylights framework.

OpenDaylight Sodium logo

[Release] OpenDaylight Sodium, YANG Tools & MD-SAL

It is no secret, that OpenDaylight is more than a passion project here at As one of the staples in the SDN revolution, we are also proud that we are one of the largest contributors to the project, with our Fellow Robert Varga leading in the number of individual commits. Let us have a look at what is new.

YANG Tools 3.0.0

YANG Tools is a set of libraries and data modeling language, used to model state & configuration data. It’s libraries provide support for NETCONF and YANG for Java-based projects and applications.  What’s new in the world of the latest Yangtools release?

It implements new RFCs: RFC7952 (Defining and Using Metadata with YANG) and RFC8528 (YANG Schema Mount).

YANG parser now supports RFC6241 & RFC8528, while adding strict QName rules for “node identifiers”.

JDK11 support has been added together with lots of small bugfixes, which you can read in detail in its changelog.

MD-SAL 4.0.0

The Model-Driven Service Abstraction Layer is OpenDaylight’s kernel – it interfaces between different layers and modules. MD-SAL uses APIs to connect & bind requests and services and delegates certain types of requests.

The new version of MD-SAL has been released for ODL. MD-SAL is one of the central OpenDaylight components. This release contains mainly bugfixes and brings pre-packaged model updates for newly released IETF  models: RFC8519, RFC8528, RFC8529, RFC8530.

OpenDaylight Release Sequence

Get ready for OpenDaylight Sodium

OpenDaylights development has a new important milestone ahead: the Sodium release, currently scheduled around September 2019. This release will bring new versions of YANG Tools, MD-SAL and other core OpenDaylight components.

JDK11, as well as JKD8, is supported, providing an opportunity for OpenDaylight users to try new features of JDK11. It bids farewell to Java EE modules & JavaFX, as well as performance & bug fixes.

We believe you are also looking forward to these releases and encourage you to try them out!

Don’t forget to contact us, in case you are interested in a commercial solution for your business!

You can contact us at

Explore our Pantheon GitHub.

Watch our YouTube Channel. & OpenDaylight is the 2nd largest OpenDaylight contributor for Q3/2018

In the last week of November 2018, Bitergia, a software development analytics company, published a report on the past and current status of the OpenDaylight project, which plays a significant role in’s offerings and solutions.’s CTO Robert Varga, is leading the list of per-user-contributions to the source code of OpenDaylight, with over 980 commits to the source code in Q3 of 2018. This achievement further establishes’s position as one of the largest contributors to the OpenDaylight project.

As for the list of companies which contribute to the source code of OpenDaylight, is the 2nd largest contributor for Q3/2018, with 1034 commits. We were just 34 commits shy of the top contributor position, which belongs to Red Hat.

Due to ODL’s open-source nature, anyone can contribute to the project and improve it in the long-run. Any change that gets added to the source code is defined as a commit. These types of changes need an approval and can not be any type of automated activity – including bot-actions or merges. This means, that each single commit is a unique change, added to the source code. will continue its commitment to improving OpenDaylight and we are looking forward to being a part of the future of this project.

What is OpenDaylight?

ODL is a collaborative open source project aimed to speed up the adoption of SDN and create a solid foundation for Network Functions Virtualization (NFV).’s nurture for ODL goes back when it was forming. In a sense, has led the way is and how an SDN controller is and should be. This requires dedication, which was proven over the years with the extensive amount of contribution thanks to its expert developers.

Click here if you are interested in our solutions, which are based on, or integrate ODL’s framework.

You can contact us at

Explore our Pantheon GitHub.

Watch our YouTube Channel.