Aerospike - proper way to develop UDFs

Question

UDF development background
I was using Aerospike 3.5.12. Initially, I wrote UDFs remotely, then registered it to Aerospike via the Java client's UDF registration method. This method was a little cumbersome (it required re-registration for every change), but worked.

Later, I found it more convenient to directly edit the file on the Aerospike server, at /aerospike_dir/usr/udf/lua/myUdf.lua. This worked conveniently. Changes made were permanent and remained even upon cluster restart (if I recall correctly).

Recently, I upgraded to 3.6.1. I found that changes made directly to /aerospike_dir/usr/udf/lua/myUdf.lua are recognized by Aerospike until the cluster is restarted. After restart, all changes are lost, and the file reverts to its original version.

Question
Is this normal behavior? How can I disable this auto-reversion? Or, if I'm not developing UDFs correctly, how should I approach it?

Answer 1

You should not be directly editing the file maintained at "/opt/aerospike/usr/udf/lua". You should always go via the registration mechanism. Its cumbersome during initial development. But once the development stabilizes, you wouldnt be rolling out changes to your lua file that frequently. There are multiple reasons to not edit the file directly.

1. When you use lua caching (which is on by default) to improve performance of udf, the changes that you do in the file directly will not be picked unless aerospike server decides to refersh its cache. You cannot predict when this will happen. You shouldn't depend on this. Registration will refresh the cache
2. In a multi-node cluster scenario, how will maintain sync of the lua files ? Will you update files on all the nodes and what if you add a new node ? Isn't it more cumbersome ? The registration mechanism takes care of distribution of the lua file on all the nodes of the cluster. It also takes care of distribution to the new nodes that may join the cluster later.