Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Andrei Alecu
    @andreialecu
    it would only occur if you called the internal client without a callback, though there was no reason to do that in theory
    Nicolas Ritouet
    @NicolasRitouet
    indeed, that’s weird
    Eric Fong
    @ericfong
    Sorry, over the weekend, I am too busy. Will catch up and rebase this two days
    Nicolas Ritouet
    @NicolasRitouet
    hey @ericfong , no need to be sorry, we're not a company, we're benevolent and it's already awesome what you're doing for the project !
    Andrei Alecu
    @andreialecu
    @ericfong did you get that memory leak sorted?
    Eric Fong
    @ericfong
    One month: 1 - 2 times restart. acceptable for me for my stage
    Andrei Alecu
    @andreialecu
    I was talking about that fix I made
    which was just committed
    did you see memory leaks after it? is memory usage still increasing?
    Eric Fong
    @ericfong
    I put that into my staging machine, which is still running (~500MB now).
    Andrei Alecu
    @andreialecu
    that sounds like a lot
    it shouldn't increase too much from a base value
    Eric Fong
    @ericfong
    Thanks @andreialecu for your PR. Let's try to follow the subject format in: https://github.com/deployd/deployd/blob/master/CONTRIBUTING.md#type
    https://github.com/deployd/deployd/blob/master/CONTRIBUTING.md#subject
    which don't capitalize first letter
    May be my problem have some internal problems. try to study that later
    Andrei Alecu
    @andreialecu
    deployd/deployd#484 I updated the code here
    didn't like checking for function name, I check if a promise is returned now
    Andrei Alecu
    @andreialecu
    @ericfong are you running your code with env=production?
    Eric Fong
    @ericfong
    YES
    Andrei Alecu
    @andreialecu
    ok, because that memory leak thing fix I did doesn't apply for development, it would still leak
    https://github.com/deployd/deployd/blob/master/lib/config-loader.js#L36 not sure why it wouldn't want to cache for development
    Eric Fong
    @ericfong
    may be other reasons. Thanks
    Andrei Alecu
    @andreialecu
    I think the reason is so that you can edit event scripts in a text editor instead of the dashboard without restarting the node process every time
    though that would be better done by watching the files for changes via fs.watch
    Andrei Alecu
    @andreialecu
    deployd/deployd#384 this can be closed probably
    Andrei Alecu
    @andreialecu
    deployd/deployd#480 any chance this could be merged soon-ish? It's innocent enough, only a testing infrastructure thing
    and as with the phantomjs runner, it's very important to ensure code correctness, I keep having to merge it and test then revert
    Andrei Alecu
    @andreialecu
    and by the way: deployd/deployd#476 , another positive side effect of the dpd cli change in this PR is that it tests if the cli works properly and can spawn a mongod instance. previously there were no tests for that - this at least ensures that npm test will fail if there is something wrong somewhere in /bin/dpd
    Nicolas Ritouet
    @NicolasRitouet
    @andreialecu , I just rebased your PR, thx
    Andrei Alecu
    @andreialecu
    just saw that, thx
    I'm fixing something else I found, just caught it while working on my stuff
    expect new PR
    should be minor
    Nicolas Ritouet
    @NicolasRitouet
    ok :sparkles:
    Andrei Alecu
    @andreialecu
    deployd/deployd#485
    is this squashable? I pushed to the same branch I used before instead of making another
    Andrei Alecu
    @andreialecu
    the bug I fixed in #486 actually appeared in the wild once here: https://travis-ci.org/deployd/deployd/builds/46467404 in a randomly failed travis build
    in my case I could not actually login a user and retrieve it without crashing deployd without this fix. because my mongo is not on the same network as where I'm hosting my app
    Andrei Alecu
    @andreialecu
    @ericfong or @NicolasRitouet , if you have production apps can you check db.sessions.stats()
    the session handling in deployd is so rudimentary at this point that the table grows indefinitely and can even create a new session on every request without ever deleting any of them
    deployd/deployd#314
    I have 7451 sessions in mine without any actual production so far, just my testing
    Nicolas Ritouet
    @NicolasRitouet
    "count" : 11803
    but I have something like 5 users using the app almost everyday
    Andrei Alecu
    @andreialecu
    there is a huge issue in the code where if you don't resend the sid cookie that was first generated it will create a new session every time
    Nicolas Ritouet
    @NicolasRitouet
    ok
    Andrei Alecu
    @andreialecu
    this is especially possible across servers with CORS
    for example the $http object in angular needs an extra flag passed to it {withAuthentication: true}
    otherwise the cookie is not sent by default, thus creating sessions on every single request
    it's also impossible now to log out a user without deleting the session from mongo directly, they never expire
    once logged in you'll be logged in forever