Several commands are returning empty replies (or errors)

[iDJHost]

Commands not working:

avatar_name
Response: <restbot><name></name></restbot>
avatar_key
Response: <restbot><key>00000000-0000-0000-0000-000000000000</key></restbot>
avatar_online
Response: <restbot><error>parsekey</error></restbot>
avatar_profile
Response: <restbot><error>not found</error></restbot>
avatar_groups
Response: <restbot><error>not found</error></restbot>

list_inventory (without key parameter because I don't have any known keys yet.) 
"With an empty key, it starts from the root folder;"
Response: <restbot><inventory></inventory></restbot>```

[GwynethLlewelyn]

Could you be a tiny bit more specific? You should have some logs.
Also, it would be nice to have an idea on the full command line you have used. I'm assuming you're testing with curl, right? Or are you using Postman or something similar?

[iDJHost]

Sorry the text editor didn't want to show the "xml"

Updated original issue with code block to see the xml tags.

[iDJHost]

Could you be a tiny bit more specific? You should have some logs. Also, it would be nice to have an idea on the full command line you have used. I'm assuming you're testing with curl, right? Or are you using Postman or something similar?

If you let me know the directory for the logs, I'll gladly share them.
Full commands where the same as what is provided in the API link.
Tested using command line curl.
(I will be working on a webgui in the near future that I might share when it's completed.)

[iDJHost]

Also, untested in SL, but in OpenSim after a while the bot just logs out.
I think I found the log file, I'm going to clear it and test again and will upload the logfile here.

[iDJHost]

Commands:

curl http://localhost:30002/avatar_name/4068b7b5-3eb2-4132-950a-de63c5d6166d -d key="48288bed-be0c-4785-828a-c636fbbd9591"
<restbot><name></name></restbot>
(tested again without quotes, same response)

curl http://localhost:30002/avatar_name/4068b7b5-3eb2-4132-950a-de63c5d6166d -d name="Jym%20Nova"
<restbot><key>00000000-0000-0000-0000-000000000000</key></restbot>
(tested again without quotes, same response)

curl http://localhost:30002/avatar_online/4068b7b5-3eb2-4132-950a-de63c5d6166d -d key="48288bed-be0c-4785-828a-c636fbbd9591"
<restbot><error>parsekey</error></restbot>
(tested again without quotes, same response)

curl http://localhost:30002/avatar_profile/4068b7b5-3eb2-4132-950a-de63c5d6166d -d key="48288bed-be0c-4785-828a-c636fbbd9591"
<restbot><error>not found</error></restbot>
(tested again without quotes, same response)

curl http://localhost:30002/avatar_groups/4068b7b5-3eb2-4132-950a-de63c5d6166d -d key="48288bed-be0c-4785-828a-c636fbbd9591"
<restbot><error>not found</error></restbot>
(tested again without quotes, same response)

curl http://localhost:30002/list_inventory/4068b7b5-3eb2-4132-950a-de63c5d6166d
<restbot><inventory></inventory></restbot>

RESTbot logfile here: RESTbot.log
If there is a different file you'd like to see, let me know.

[GwynethLlewelyn]

Whoops. My apologies for the delayed reply!

I can confirm that I can reproduce your bug, thanks for reporting it! I'm testing on Second Life, but the issue shouldn't be different on OpenSimulator (I'll test that as well once I figure out what's going on).

My logs are the same as yours, so, clearly, something is quite wrong here!

The problem went undetected for quite some time because, well, in my own environment (in production!), by sheer chance, I don't use any of those commands... what a mess!

What is happening is that the lookups time out too early — not necessarily because there is something wrong with the grid, but rather because of a bug that crept in on the RESTbot side. I can see that there is a NULL_KEY where there shouldn't be; this usually means there is some uninitialised variable somewhere (or, worse, badly initialised), and since seems to affect all timeout loops (not just the one for avatar_name, as I originally thought), it's a systematic error with the code dealing with replies from the grid server(s).

It used to work — I'm pretty sure of that! — but I'm also aware that I've been tinkering a lot with the original code for these lookup procedures. I might have broken it at some point, and now I need to fix it again.

Sorry about that!

To make matters worse, my current development environment suddenly became out of sync with Microsoft's .NET management, and now I get a lot of errors related to outdated library versions being accessed... dang!

It looks like it's time to give this project some Gwyn love ❤️

I've also seen some erratic login behaviour on just one bot. Why exactly just that one, while the others are unaffected, seemed to be a mystery to me — until I could trace it down to RESTbot getting confused about its internally managed sessions. It looks like sometimes one of these session IDs will be 'lost', and, as a consequence, RESTbot is unable to contact the grid again in order to keep the session alive. The 'bot attempts to log in, but RESTbot fails to retrieve a valid session for it, so the 'bot times out and drops out the grid... after 5 minutes (the default), RESTbot tries to log it back in, the same happens, the 'bot logs off... and that repeats ad æternum. Clearly something is wrong, and possibly related to your own issues regarding 'bots that do not stay in-world, no matter what.

This becomes more pronounced after having RESTbot running continuously for several days. Issue #8 is an ongoing effort to figure out where exactly memory is being leaked and why. Initial memory allocation is about 1 MByte, which is technically more than enough; but after a few days, it's consuming several GBytes. Granted, that's virtual memory, not really resident memory (= physical memory in use), but, nevertheless, it shows that something is not right.

Also, there seems to be an increase in CPU resources (as well as disk writes), both strange (and suspicious!), since in my case, I have a dozen bots mostly doing nothing; thus, there shouldn't be a growing amount of resource consumption over time, if things haven't changed.

Well, all that merely shows the little knowledge I have about all this :-) Bear with me as I try to figure out a way to get it working again...

[GwynethLlewelyn]

All right... half a year later, and I haven't successfully fixed this. One note, though: it seems that the KLE (Key Lookup Event) successfully executes and retrieves the correct parameters; however, when returning back to the function invoking the KLE mechanism, it seems to 'forget' what it had just written — and thus the above-mentioned errors! (which I can faithfully reproduce).

Other functions which do not require using the KLE mechanism will have no issues (and that's why my own code works fine!). It also explains why I could never teleport to anywhere: when using the goto API command, it invokes the KLE to get some information for the destination region. This fails, so the system doesn't know what region to contact, causing the API call to prematurely fail, even though all data has been processed correctly.

Well, this means narrowing my focus: having pin-pointed all the above issues to the return of the KLE mechanism — whereby information gets lost! — once I fix that, everything else should get fixed as well.

[Outworldz]

I;ve not reviewed any of this, but I do follow it. It may be different threads are involved. When I run into this I push an object that contains what I want onto a Concurrentdictionary object. Then use that in other threads.

[GwynethLlewelyn]

Hm! It's worth giving it a try...