Closed technobly closed 11 years ago
Example code also available here: https://gist.github.com/DubbyTT/5789633
Also compiled bot.js file if you wanna try it right now :) https://gist.github.com/DubbyTT/5789639
@DubbyTT epic xD, ima try this out tonight. and yes definitely much appreciated, thanks
:o This Is so awesome :D
This is so cool.
I've actually got code that keeps the watchdog in ttapi proper, and emits a 'disconnect' event if no responses to the periodic presence update are heard. While I don't see any significant conflict with these changes, code-wise, the idea is simpler to implement and, in my opinion, simpler to use (because it requires only one handler). I'll see if I can get it wrapped up and provide an example.
@gizmotronic sounds interesting I'd like to see it. I actually chose to implement it this way to put the burden of staying logged in on the user's bot code rather than the TTAPI for a couple reasons. Maybe you want to do some stuff before logging back in, maybe you don't want it to log back in, and you don't have to add any setIntervals to the TTAPI. Furthermore @alaingilbert likes simple so I figured the only way he would add this to the TTAPI would be if I kept it that way.
It seems pretty obvious now when you look at what I added, but it was a pain in the ass to find and figure out. The connect code didn't have any error reporting so there was no way to know when the websocket connection dropped. The whichServer calls didn't have any error trapping, so I added that to prevent calls to roomRegister from throwing an exception. I also added a way to know if the bot is really logged in or not, i.e. the 'alive' message, which is used to reset the watchdog. I know you can simplify what I did, and I'm sure you will, but I still feel proud to have figured this out all on my own, and be the first to document it ;-)
Have fun keeping your bots logged in.
this is confirmed working, thanks again man :+1:
@DubbyTT my implementation leverages the existing setInterval(), and doesn't require a separate watchdog timer in either ttapi or the user's code. I'll refrain from further comment until I have something to show, though. :)
cool, I hope @alaingilbert sees this so we can get TTAPI updated.
@samuri51 you're welcome ;-)
@DubbyTT Code works great. my next request is for you to code up a queue manager, if you don't already have one on ChattyTT.
@Turntablelover queues are very hard to do right. Just warning you now.
How's your codeacademy.com work coming along, @Turntablelover? You'll probably get a queue manager faster if you learn how to write it yourself.
@gizmotronic it's going along fine
@alaingilbert any idea when this can get pulled into the core?
Will this be on npm shortly?
Done ! Thanks @DubbyTT for your good work :) @MikeWills -> Version 2.4.0 has it.
@alaingilbert Thank you :) I appreciate it :heart:
So @DubbyTT. How do you run this then? Can you just run using the normal nohup so you can run it in the console and it'll stay running?
nohup node mybot.js > foo.out 2> foo.err &
I am coming from running forever to make sure my bots stayed up.
Luckily my bot is so well debugged and error protected, that I haven't really needed to use something like a process monitor such as Forever. The autoreconnect.js example just reconnects your bot if it loses a connection with the registered room. It does not do anything yet that would restart your bot it it crashed entirely. That said, I have been working on a very simple monitor just for bots.
On windows you would just use:
node mybot.js
I suppose you could use your nohup
command if you are on some kind of linux system that you shell into, but you may not absolutely need it. It might be nice for capturing the logs though.
Yah yah yah... we aren't all perfect like you. :-)
Okay, I assumed that was the case... but I had to make sure. Imma try it with one bot first then propagate to the rest.
@DubbyTT woot woot, you released it :wink:
@MikeWills "I'm not perfect... ...yet." -MacGyver
BTW... I just finished a mean process monitor in 90 lines of code. Handles multiple processes defined as paths to your node scripts in an array. This allows you to start everything just by running the master process. If any crash, it will declare them 'offline' after a programmable threshold in seconds, and then restart them after a separate threshold in seconds. You do have to add a tiny code block to each process... but in my opinion this makes it much more reliable... and we can afford to do that easily. Once I do some real live testing with this, I'll put it on Github.
I thought you retired from TT... :-)
Thanks man!
I don't like leaving things unfinished....
@MikeWills You can't retire from good music. :stuck_out_tongue:
@mnafricano Trust me! I know... I am going on my third year.
@MikeWills I'm currently running this on all of my bots... hope it stays working like it has been because it's been fantastic! :) https://github.com/DubbyTT/MonStar
Some things I might like to add, automatic color coding of processes, command line interface for "exit", "kill
Could you share that me? I think on Sunday I might try to make those changes on my bots for the uptime code. I could help test on another bot your script. Could just email it to me directly.
@MikeWills it's right here... https://github.com/DubbyTT/MonStar/blob/master/monstar.js and I don't know your email. @yayramen already rewrote the whole thing this morning for his bots, he seems to like it ;-)
Much awaited and hopefully much appreciated code to keep all of your turntable.fm bots connected ... always!