I fixed a leak found during large file transmission in the forwarding path, but during the work observed that it is possible for transactions to stay forever in the tree on the server node.

Currently each allocated transaction is stored on every node which does not process it locally. When it is stored on the client, who originally sent write request, it can be accepted - client may want to resend it (although there is no exported API to access the tree). Each forwarding server actually may do the same - transaction is stored until explicit acknowledge is received from the remote node, so we can check wheather it is the last packet for this transaction and free it after forwarding reply back to the previous node (which may or may not be the original client).

The problem is node can go offline so all unacked transactions from that server will stay forever in the tree on the other nodes. There is no mechanism currently for timeout scanning of the tree and resend or free stale transactions (like we have in POHMELFS). So server can still 'leak' if client or other nodes failed and there were unacked transactions. Also stale transaction processing should just drop old transaction on the intermediate nodes and only original client should resend it, since otherwise multiple nodes, which were used to forward the same request one to another, may decide to resend the same data multiple times and break the real order of the updates.

Solution is rather simple - introduce resend timer and check the tree for the stale data. But it is not that simple actually - as a general purpose library, elliptics network can be used in the projects which already have own alarm handlers, and naive timer introduction can break the things. As a solution I can implement a 'clean up' API, which can be called from the user's code to resend or free stale transactions, and timer registration callback if user does not use alarm handler.

In a meantime we are ready for the 2.5.1 bugfix release, but I want to check some bits first. Stale trasaction processing is scheduled for the next one. Stay tuned!