Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Jun 23 14:26

    niemyjski on master

    Updated npm tag badge (compare)

  • Jun 23 14:21

    niemyjski on v2.0.0-beta1

    (compare)

  • Jun 23 14:20

    niemyjski on master

    Remove useReferenceIds (compare)

  • Jun 23 14:18

    niemyjski on master

    Remove useSessions from read me (compare)

  • Jun 23 13:56

    niemyjski on master

    Updated default data example (compare)

  • Jun 23 13:47

    niemyjski on master

    updated read me layout (compare)

  • Jun 23 13:46

    niemyjski on master

    Updated read me documentation (compare)

  • Jun 22 13:32
    niemyjski commented #66
  • Jun 22 13:31
    niemyjski commented #76
  • Jun 22 13:31
    niemyjski closed #76
  • Jun 22 13:30
    niemyjski closed #94
  • Jun 22 13:30
    niemyjski commented #94
  • Jun 22 13:30
    niemyjski commented #89
  • Jun 22 13:29

    dependabot[bot] on npm_and_yarn

    (compare)

  • Jun 22 13:28
    dependabot[bot] commented #101
  • Jun 22 13:28
    niemyjski closed #101
  • Jun 22 13:28

    niemyjski on workspaces

    (compare)

  • Jun 22 13:28
    niemyjski closed #95
  • Jun 17 19:32
    mpawelski commented #31
Sander Rijken
@srijken
you don’t want that filling up though
Eric J. Smith
@ejsmith
yes, it’s happening on a bg thread.
Blake Niemyjski
@niemyjski
errors happen at random..
developers control there logs
Eric J. Smith
@ejsmith
and the time that it will take to do hashcodes will be very small compared to any code doing real work.
Sander Rijken
@srijken
I’ve hit some errors happening so fast that I’m sure there would’ve been a delay.. or at least a good benchmark test for this :D
it’s far faster than sending all the http requests one by one for sure
Eric J. Smith
@ejsmith
exactly
Blake Niemyjski
@niemyjski
so question
eh never mind
dumb question
Sander Rijken
@srijken
lol
Blake Niemyjski
@niemyjski
was going to ask why we need a time on the processed queue
but its because if they aren’t very active it should be ignored
:)
Sander Rijken
@srijken
and then you figured it out :)
Blake Niemyjski
@niemyjski
yeah
Eric J. Smith
@ejsmith
we should use the timer pattern that we are using in the in memory queues and other things from foundatio
where the timer only fires exactly when it needs to.
Blake Niemyjski
@niemyjski
eh
once every 60 seconds
not really worried about that...
Sander Rijken
@srijken
and the only thing it does is try to dequeue an event
Blake Niemyjski
@niemyjski
ooh crap just thought of something
Sander Rijken
@srijken
it’s not doing a ton of work
Blake Niemyjski
@niemyjski
if we are waiting 60 seconds
then shutting down randomly
become a bigger issue
as you just lost a minute of data
Sander Rijken
@srijken
other thing.. I think .Send() needs to be wrapped in a try{} catch{}?
Eric J. Smith
@ejsmith
it should send before dispose
which will put them in the queue
if they have persistent queues… they will be saved.
Sander Rijken
@srijken
you don’t want exceptions to break out of the timer event.. it’ll crash the app hard
Eric J. Smith
@ejsmith
yeah
we have to be super careful to not crash people’s apps. :-)
Blake Niemyjski
@niemyjski
no
they are in memory queues inside of the plugin
and will sit there for up to 1 minute
Eric J. Smith
@ejsmith
yes, I know… but dispose gets called.
Sander Rijken
@srijken
yeah but if you send it from the dispose, you can send it earlier
Blake Niemyjski
@niemyjski
hmm
Eric J. Smith
@ejsmith
it needs to submit any pending in the dispose
Blake Niemyjski
@niemyjski
yeah
Sander Rijken
@srijken
except when dispose doesn’t get called..
Blake Niemyjski
@niemyjski
good call
Sander Rijken
@srijken
but then it just sucks anyway
Eric J. Smith
@ejsmith
in that case we are screwed anyway
Blake Niemyjski
@niemyjski
but will dispose actually get called on shutdown
might be wayyyyy too late