Roll20 uses cookies to improve your experience on our site. Cookies enable you to enjoy certain features, social sharing functionality, and tailor message and display ads to your interests on our site and others. They also help us understand how our site is being used. By continuing to use our site, you consent to our use of cookies. Update your cookie preferences .
×
Create a free account

[HELP] Problem with asynchronous (maybe?) sendChat in script

1431911209

Edited 1431911439
First let me apologize for beating insanely on the rollserver trying to find this bug. My script is intermittently producing There was an error communicating with the QuantumRoll server. I think it has to do with quick re-entry to the rollserver in the same script; I found sendChat is non-blocking, and it is possible to receive sendChats out of order, so they're clearly not synchronous. Reproducing the error from my script is more than tedious, so I pulled out one of the sendChats that was occasionally failing, and hardcoded it into a tight loop as follows: var Testoonie = Testoonie || (function(){ var handleMsgInput = function(msg) { if (msg.type !== "api" || msg.content.indexOf("!testoonie") === -1) return; // fall through must be !testoonie - parse the opts sendChat("Testoonie", "/roll 9d6"); var msgout = "&{template:5eDefault} {{action=1}} {{title=Ram}} {{subheader=Giant Elk}} {{subheaderright=Melee attack}} 0 {{action_show_attack=1}} {{action_attack=[[d20cs&gt;20 + 6 + (0)]]}} {{action_show_attack_adv=1}} {{action_attack_adv=[[d20cs&gt;20 + 6 + (0)]]}} {{action_can_crit=1}} {{action_crit_damage=[[2d6 + 0d0]]}} {{action_crit_damage_adv=[[2d6 + 0d0]]}} {{action_alt_crit_damage=[[0 + 0d0]]}} {{action_alt_crit_damage_adv=[[0 + 0d0]]}} {{action_second_crit_damage=[[0 + 0d0]]}} {{action_second_crit_damage_adv=[[0 + 0d0]]}} 0 {{action_show_damage=1}} {{action_damage=[[2d6 + 4 + (0) + 0d0]]}} {{action_damage_type=bludgeoning}} 0 0 0 0 0" // var msgout = "/roll 10d10"; log(msgout); for(var i=1; i&lt;100;i++){ // sendChat(performerName, "" + i + "[[5d20]]" ); sendChat("Testoonie", msgout ); // sendChat(performerName, "" +i); } }; // END OF script input commands var registerEventHandlers = function() { on('chat:message', handleMsgInput); }; return { // CheckInstall: checkInstall, RegisterEventHandlers: registerEventHandlers, }; }()); on('ready',function() { // 'use strict'; Testoonie.RegisterEventHandlers(); }); Interestingly, the message has to be complicated enough to produce the error. "/roll 10d20" for example wouldn't do it, regardless of how fast you pump it out. That's why the long attack-template roll message is in there. So it must have something to do with delaying the parsing of the message long enough to trigger a race condition (or something like that). At the current time, from my laptop, the above test script will consistently produce the "communicating" error, after about 40-60 chats are pumped. So if you pound on the rollserver hard enough, you'll get the error. I'm hoping the above is the same problem I'm having in my script. I guess I want to make sendChat block, or synchronize my script. But I'd rather not guess on what's going on here. Can you explain it? Will blocking on sendchat help, or will that just prevent every script from running? If I need to synchronize just ONE script and not all my running scripts, what strategy would you suggest? A script-specific semaphore? Is there an easy hook I can use or a pattern you'd suggest? I understand concurrency, but I am new to javascript, so I don't know much about JS's model of multiprocessing or multithreading. I doubt looking at my full script will help, but if you want: <a href="https://github.com/computed/rolledCode/tree/master" rel="nofollow">https://github.com/computed/rolledCode/tree/master</a>...
1431915167
Lithl
Pro
Sheet Author
API Scripter
There's a JS implementation of Asynchronous Semaphore on the wiki. I don't know if it would solve your problem, but it might help.
1431915532
The Aaron
Roll20 Production Team
API Scripter
I was able to duplicate the issue with your script.
Brian said: There's a JS implementation of Asynchronous Semaphore on the wiki. I don't know if it would solve your problem, but it might help. Thanks Brian. I could use that or similar and queue up my own sendChats on the script side, but I would like to hear from dev what they think the problem might be before trying to solve it. I'm assuming this forum is for the dev folks to look when they get a few minutes to spare. Or is there another way I'm supposed to ask them for help?
1431959819
The Aaron
Roll20 Production Team
API Scripter
This is the correct first step.
1431973148
Stephen Koontz
Forum Champion
Marketplace Creator
Sheet Author
API Scripter
Compendium Curator
Depending on the content of the message it will be handled by our servers in a different manner. Rolls have to be sent to the quantum roll server, plain text doesn't. Obviously complicated rolls will take longer to return than simple ones. Just so I'm sure I'm understanding the issue comes from sending several complicated rolls in rapid succession and sometimes it throws the "There was an error communicating with the QuantumRoll server." error?
1431985211

Edited 1431986106
That's correct. You can see I produced the error with the test script posted here by pumping out 100 rolls, but on Sunday it could be triggered by as few as three rolls in quick succession, wherein the previous two roll results were already resolved on the display before the third one is sent. The third roll might produce the error. As the day went on, the errors became more intermittent = less frequent. Some subjective impressions and thoughts that may be helpful (or possibly not, ignore at your leisure): - It was sunday so I expect you had a fairly heavy load on your servers with lotsa gamers. - I had the impression the roll immediately prior "hesitated' before displaying. Like the round-trip lag time had increased. Then the next roll would produce the error. - I can get results for the same roll to respond out-of-order as well, so the time is not just dependent on complexity of the roll. Maybe network lag and possibly multi-threading on your roll server is involved? I figured you're aware of this anyway. I don't see how that matters, but more information is more information.. - I was speculating that it "felt like" it might be a socket connection issue, something like hitting a connection on the rollserver while its in the process of being reclaimed. If it's something that's hard to dig out, maybe there is try/catch exception or status test I could use? I don't mind missing the occasional roll as much as having the scripts turned off.
1432059984

Edited 1432060803
Riley D.
Roll20 Team
Well, it looks like your benchmarking script at the top is sending something like 500 rolls in the space of a second to the QuantumRoll server. While we have quite a bit of capacity there, I don't think it will probably handle that many rolls from a single source in such a short amount of time. We did have a time on Sunday where the QuantumRoll server went down for the space of about 5 minutes ( <a href="http://status.roll20.net/1217512" rel="nofollow">http://status.roll20.net/1217512</a> ) ...but you're saying you were getting the error intermittently throughout the whole day? What is the script that you are seeing the error with normally (not the benchmark script)? As an aside, I will look into adding fallback functionality like what we've added to the main client where if QuantumRoll is unavailable, your rolls will fall back to the local dice engine (the one the API used until a month ago) instead of just erroring out...
The original script is in my top post, here it is again: <a href="https://github.com/computed/rolledCode/tree/master" rel="nofollow">https://github.com/computed/rolledCode/tree/master</a>... It would take a bit of configuring campaign conditions to reproduce the exact situation that produced the error, so I doubt the script will help much for testing. If your intention is to check my code for bugs, then thanks in advance! And thanks for looking into it. Parenthetically, it seems to me NOT to be a volume problem per se, but to be a socket timing or packet contention problem. The volume "benchmarking" script just seemed a reliable way to produce something similar to the error I was getting. Can you let me know when the fallback is installed? (Then I'll consider getting back to script revisions..)