Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
Blake Niemyjski
@niemyjski
so it’s changing that on request info
should we remove cookies from the gethashcode logic too
?
Eric J. Smith
@ejsmith
no
why would we do that?
if the cookies are different, don’t we want to see them?
Blake Niemyjski
@niemyjski
because were updating the lastreferenceid cookie value and then it’s not deduped
yeah I guess but if everything else matches then it’s kind of a dup no?
Eric J. Smith
@ejsmith
yeah, that sucks
if we can skip that one
that would be good.
Blake Niemyjski
@niemyjski
only
yeah I’ll add logic to skip that key on gethashcode
you think we should remove the threadid,thread name, available memory and process memory size from gethashcode
to me those are things that could change alot
but having those may help track down multithreaded issues
Blake Niemyjski
@niemyjski
DuplicateCheckerPlugin: Checking event: with hash: -1999577676
DuplicateCheckerPlugin: Checking event: with hash: -25846723
DuplicateCheckerPlugin: Checking event: with hash: -25846723
DuplicateCheckerPlugin: Checking event: with hash: -688792890
DuplicateCheckerPlugin: Checking event: with hash: -25846723
DuplicateCheckerPlugin: Checking event: with hash: -1999577676
DuplicateCheckerPlugin: Enqueueing event with hash:-1999577676 to cache.
DuplicateCheckerPlugin: Enqueueing event with hash:-25846723 to cache.
DuplicateCheckerPlugin: Enqueueing event with hash:-1999577676 to cache.
DuplicateCheckerPlugin: Enqueueing event with hash:-25846723 to cache.
DuplicateCheckerPlugin: Enqueueing event with hash:-688792890 to cache.
DuplicateCheckerPlugin: Enqueueing event with hash:-25846723 to cache.
were using a concurrent queue
and it’s almost like it’s blocking
Eric J. Smith
@ejsmith
I think removing those is reasonable
Blake Niemyjski
@niemyjski
yeah I removed them now running into some kind of issue with the above
seems like there getting blocked when you queue up a bunch of them and then they are allowed
Eric J. Smith
@ejsmith
don’t know what you mean
Blake Niemyjski
@niemyjski
look at the above log message
Blake Niemyjski
@niemyjski
updated the unit test and it’s failing
Blake Niemyjski
@niemyjski
            c.UseLogger(new XunitExceptionlessLog(_writer));
:D
got awesome logging now in our client unit tests
Blake Niemyjski
@niemyjski
Checking event: with hash: 738490750
Checking event: with hash: -717263284
Enqueueing event with hash:-717263284 to cache.
Checking event: with hash: -717263284
Enqueueing event with hash:-717263284 to cache.
Checking event: with hash: -717263284
Enqueueing event with hash:-717263284 to cache.
Enqueueing event with hash:738490750 to cache.
Checking event: with hash: -717263284
Checking event: with hash: -717263284
def having a threading issue
with the plugin
changed the forloop to a parallel 4 and everything broke loose
Blake Niemyjski
@niemyjski
@srijken would you be willing to help me look into why the concurrent ones are failing? I added unit tests with improved logging
I think we might need to add some locking code in there
which is both scary and sucks
Blake Niemyjski
@niemyjski
I Added a lock around all of it
and it increased the run time quite a bit
I’m also seeing a weird issue where 1 out of 4 runs fails with invalid hashcode
Enqueueing event with hash:-1799816918 to cache.
Adding event with hash:-1799816918 to cache.
Enqueueing event with hash:825815748 to cache.
Ignoring duplicate event with hash:-1799816918
Ignoring duplicate event with hash:-1799816918
Ignoring duplicate event with hash:-1799816918
Ignoring duplicate event with hash:-1799816918
Ignoring duplicate event with hash:-1799816918
Ignoring duplicate event with hash:-1799816918
Ignoring duplicate event with hash:-1799816918
same code paths and event being generated
Blake Niemyjski
@niemyjski

DeduplicationBenchmarks_IdenticalExceptions, 116 runs

DeduplicationBenchmarks_IdenticalExceptions - 0.01ms

DeduplicationBenchmarks_LargeEventsFromFiles, 103 runs

DeduplicationBenchmarks_LargeEventsFromFiles - 0.30ms

DeduplicationBenchmarks_RandomExceptions, 110 runs

DeduplicationBenchmarks_RandomExceptions - 0.01ms

that’s what it was before my change
lets see what it is on the build server now
@ejsmith @srijken feedback on this is greatly appreciated: exceptionless/Exceptionless.Net@9a34941

DeduplicationBenchmarks_IdenticalExceptions, 114 runs

DeduplicationBenchmarks_IdenticalExceptions - 0.01ms

DeduplicationBenchmarks_LargeEventsFromFiles, 214 runs

DeduplicationBenchmarks_LargeEventsFromFiles - 0.31ms

DeduplicationBenchmarks_RandomExceptions, 112 runs

DeduplicationBenchmarks_RandomExceptions - 0.01ms

didn’t seem to slow it down any
Blake Niemyjski
@niemyjski
@frankebersoll https://github.com/sergeyt/karma-typescript-preprocessor/issues/30#issuecomment-99655328 looks like the tooling is starting to support typescript a bit better :)
Sander Rijken
@srijken
Hi, reading
agree on removing those properties from gethashcode
locking thing.. it’s weird that it’s necessary?