IRI and client libraries update Feb 22
The full article was originally published by Jakub Cech on Medium. Read the full article here.
In the last update, we outlined some ongoing work on both IRI and the client libraries. This post will mainly summarize the work that has been going on and its results.
If you have questions on the day-to-day development of IRI and clients libraries, please join the #iri-discussion and #clients-discussion Discord channels!
Yesterday, we released a new version of IOTA IRI with some very needed performance and stability fixes. You should be seeing the resource, especially CPU, utilization drop significantly once your node syncs.
There are still multiple things that we need to improve in terms of stability and synchronization performance, but our testing shows that 1.6.1 should definitely be a step in the right direction, with lower resource consumption in previously very strained scenarios.
List of fixes:
– Fix: Db exists() method optimization
– Fix: Do not persist pruner state (#1342)
– Fix: Reduce db access and cpu usage needed to persist spent addresses
– Fix: Added a NULL_HASH check for genesis transaction (#1309)
– Feature: Fresh transactions to request (#1316)
– Fix: missing user-agent header in cors (#1319)
– Fix: Batch process spent addresses to avoid out of memory issues (#1314)
– Fix: added a buffer to LSManager (#1286)
– Fix: test existence of spent addresses db do not point to correct folder (#1305)
– Fix: Creates rest endpoint for iotaconfig related settings as suggested (#1200)
– Fix: make storeMessage store transactions (#1186)
– Feature: Add configurable variables for spent addresses DB (#1274)
– Fix: Posting invalid json to IRI will result in detailed error message (#1202)
– Fix: dns reverse resolving issue for neighbors that are added with their IP. (#1255)
You can get IRI 1.6.1 on the releases page.
Right now, the team is focusing on building a set of nightly tests for IRI. The tests will allow us to better establish and monitor performance metrics as well as track the most important scenarios that IRI needs to support. The same goes for regression tests, where we still have some debt we need to catch up to. You can see how some of the nightly tests defined here:
- Nightly test: syncing a node from scratch
- Nightly test: node performance
- Nightly test: measuring API performance on a node
- Nightly test: syncing with different networking set-ups
- Test parallel calls to GTTA
We also have more performance improvements on the plate. We expect to start working through them shortly.
The development of the first implementation of stateful libraries for Go, Java and JS is in full swing. This is a first design that and it is likely to keep evolving. We have been gathering feedback on the approach that we implemented and we would very much appreciate your input as well.
You can find the first implementation (still in progress) for the Go and Java libraries on separate branches. The documentation is also still being developed, but we have a few pages that introduce the concepts the libraries build on.
Disclaimer: The above client libraries are in no way suited for production. They are pre-release versions that are still being developed and work with concepts that need to be validated.
If you have questions or feedback regarding the use of the libraries, please ask on the #clients-discussion Discord channel. We will be more than happy to help.
If you have not been following the projects, you can do so on our GitHub: