Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Andrei Alecu
    @andreialecu
    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
    Nicolas Ritouet
    @NicolasRitouet
    :worried:
    Andrei Alecu
    @andreialecu
    if you change the username or password, that still doesn't log the session out
    you have to change the user id to invalidate a session, that's the only way
    Nicolas Ritouet
    @NicolasRitouet
    ok
    I have to go, we can talk about that later
    Eric Fong
    @ericfong
    Scott also have point that out.
    I think we cannot fix that in the new release. But should target to fix this in next release. I hope can use 3rd party session management library instead of from deployd
    Andrei Alecu
    @andreialecu
    it's not necessarily a big fix, it can be fixed easily, we need to expose a session expiration time, and we need to not store sessions in the database unless there is an actual user login involved