"CODEC","error":"execution timeout"


#12

If one of you would like to make a pull-request to make this configurable, that would be great :slight_smile:

E.g.

[application_server.codecs.js]
max_exec_time="10ms"

#13

How solve this!!!

All my custom payloads get this error. With cayenne payload works great but not pass all the data like age, hdop or satellites. (GPS tracker)


#14

Guys,

I need to increase this timeout as well…
I do not find any customjs.go file… I’m not really familiar with theses stuffs.

Is there a way to make this timeout a bit longer?


#15

I would need some news about the guy who know… (@brocaar ? :slight_smile: )

Even we have a very simple custom code (Base64 to Hex String converison), it sometimes fall in execution timeout when we receive about 2 messages per second.

Is there way to insure that hte paylaod is decoded? Or do I have to focus my researches on another high level decoder tool?


#16

Hi genevois,

Where can I find custom_js.go file at least to change this value manually?


#17

#18

I just added this change, I’ll make a PR in a few minutes.
Oh, nevermind, it’s ready. :laughing:


#19

Ha, I just did the same :wink:


#20

Hi, @brocaar did you plan to release a version with this correction ? When do you think we will have access to the Debian packages ? Thanks !


#21

@iegomez and @brocaar, I do appreciate your support.

Nevertheless, I share the question from @SDA , because I’m not sure to be able to build it for test.
Do you plan to release a version including it?
Or is there any easy way to build and deloy?
Or even introduce it in my v2.4.1?

Hope to read you soon… :wink:


#22

I have created a snapshot for testing, please see: https://www.dropbox.com/sh/5aep3dj6llapaag/AAD2oUv3E-yx7ivO5YZYrFhfa?dl=0.

Looking forward to your feedback! Please note that I have changed the 10ms default to 100ms. You can generate a new config file using lora-app-server -c path/to/lora-app-server.toml configfile > /path/to/new-lora-app-server.toml.


#23

Thanks a lot.
Snapshot deployed.
New parameter see in the new config file

I’m going to lunch tests during next night to get some relevant statistics. I’ll let you know.


#24

Guys,

Before change:

  • 1000 messages sent, one per 5 sec
  • ==> 20% go in Timeout

After change (and timeout left as 100ms):

  • 5000 messages sent, one per 5 sec
  • ==> 0.00% go in Timeout

I am now confident with Codec usage in my use case.
Nevertheless, this test does not simulate sevral messages receive in short times.
So I continue testing it in real case with many devices pushing.

We keep in touch, but again, Thanks a lot.


#25

Gents,

New test scenario:

more than 86,000 in 24H, with pseudo random timing over 3 channels, and 3 DR.
RESULT: 100% decoding success.

So I confirm that this new parameter solves my issue (and issue is back then I set this param to previous value (10ms).

@brocaar, dod you plan to release a version including it?

Thanks by advance…


#26

Yes, I’m planning to release this this week :slight_smile: Thanks for your testing feedback!


#27

Is there a way to see how long a custom codec is taking to execute?

Right now the only way to prove how long the proper timeout should be configured for appears to be through trial and error to see how many “execution timeout” errors you get.


#28

You can always make a program using the same interpreter to run your script and check out how much it takes to get a rough estimation. Something like this:

package main

import (
	"fmt"
	"time"

	"github.com/robertkrimen/otto"
)

func main() {

	var val otto.Value
	script := `
		//Write your script here. Make it return an object so everything is tested.
		function Decode(fPort, bytes) {

			var count = 0;
			var sum = 0;
			//Let's do some things.
			for(var i = 0; i < 1000; i++) {
				count++;
				sum += i;
			}

			return {
				"Flags": bytes[0],
				"Battery": bytes[1],
				"Light": bytes[2],
			};
		}
	`
	script += "\n\nDecode(fPort, bytes);\n"

	vm := otto.New()
	vm.SetStackDepthLimit(32)
	vm.Set("bytes", []byte{1, 2, 3})
	vm.Set("fPort", 2)

	start := time.Now()

	val, err := vm.Run(script)
	if err != nil {
		fmt.Printf("js vm error: %s", err)
		return
	}

	if !val.IsObject() {
		fmt.Println("function must return object")
		return
	}

	data, err := val.Export()
	if err != nil {
		fmt.Printf("export error: %s", err)
		return
	}

	fmt.Println(data)
	elapsed := time.Since(start)
	fmt.Printf("JS script took %s", elapsed)

}

#29

I would also welcome a pull-request for this to show this as a debug(?) log message :slight_smile:

E.g.

log.WithFields(log.Fields{
    "application_id": app.id,
    "duration":       time.Since(start),
}).Debug("codec: js codec completed Decode execution")

#30

No problem, but just a quick thought: if I’m looking at it correctly, that’d involve either having to pass the app to the decode function (and thus, to other codecs too, which seems ugly) or have CustomJS hold a reference to the app or its id; or checking on the calling site for app.PayloadCodec == CustomJSType, with the added downside of timing the whole DecodeBytes call, not just the JS script running time.


#31

You’re right. Maybe this log could be added to func (a *ApplicationServerAPI) HandleUplinkData as

log.WithFields(log.Fields{
    "application_id": app.id,
    "codec":          app.PayloadCodec,
    "duration":       time.Since(start),
}).Debug("payload codec completed Decode execution")

Then it would log not only the JS codec, but all codecs :slight_smile: