Shared state async insert rate

[javierbrk]

There is a maximum insertion rate into shared state async associated to the update_interval, when you try to insert information before update_interval shared state will fail and wont inform about it.

Successive calls will end up writing.

--minimum renewal for mesh wide was 30s, once written the user hast to wait until ttl is 2400 - 30.

example: this is not writable

    {
        "key": "upgrade_state",
        "value": {
            "mAuthor": "LiMe-1f73aa",
            "mTtl": {
                "xint64": **2376**,
                "xstr64": "**2376**"
            },
            "mData": "NOT_READY"
        }
    }

is writable

        "key": "upgrade_state",
        "value": {
            "mAuthor": "LiMe-1f73aa",
            "mTtl": {
                "xint64": **2367**,
                "xstr64": "**2367**"
            },
            "mData": "NOT_READY"
        }

[ilario]

Has this been fixed in #1111?

[ilario]

Also, does this affect the 2024.1 release candidate?

[javierbrk]

Hi ! when using my custom builds from the latest main branch there is no issue. The problem was already addressed and it seems to be incorporated in 2024 branch.

The fix was included in
libremesh/shared-state-async@db58e3d#diff-c8010b427ccbce30ac1e2caa0b136aad8ff4b7fb038ef8e16f9885da868c4358R27

bring to lime-pacakges in
de9ff02

But, I have tested the build for x86 downloaded from https://downloads.libremesh.org/releases/2024.1-rc1-ow23.05.3-default/targets/x86/64/ and indeed there is a problem.

Are the x86 builds outdated ?

[a-gave]

Are the x86 builds outdated ?

This is very likely. If of any help there is a development build done in September at https://downloads.libremesh.org/development/master-ow23.05.4-527c1eb-20240905-mini/ announced in https://lists.autistici.org/message/20240908.085937.479f1ea2.en.html

[javierbrk]

Thanks ! ! Yes, the version of shared-state from mini image works great! Thanks for pointing that out. Also it seems that the mini images do not include the rpcd service which is a dependency of lime-app and I assumed it was always present. I've written some packages that give services using the rpcd interface but never added that dependency, nor the lime-app. That may not always be a problem. For example, shared-state itself offers a service using rpcd but it is not a requirement. If you don't have rpcd you just can't interact with it from another node using ubus ... but shared state will keep working. It is not vital, So no problem. Lime app using "Reference state" uses the rpcd/ubus interface to interact with other nodes who "may not" have lime-app installed. If a node does not have rpcd but has reference state packages it using lime-app with a node like that will fail. I'll review those packages and the use cases they are involved in. Saludos Ing. Javier Alejandro Jorge

…

On Wed, 27 Nov 2024 at 16:19, a-gave ***@***.***> wrote: Are the x86 builds outdated ? This is very likely. If of any help there is a development build done in September at https://downloads.libremesh.org/development/master-ow23.05.4-527c1eb-20240905-mini/ announced in https://lists.autistici.org/message/20240908.085937.479f1ea2.en.html — Reply to this email directly, view it on GitHub <#1105 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABE2I2BKDSCZTR4DQXLI46L2CYLKLAVCNFSM6AAAAABRK7XSNWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMBUGYZDIOJTGY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[javierbrk]

I have a script to test if shared-state-async has the fix, I used it to test the images.