nope
This message was deleted
hmm that’s seems odd. let me know if installing the rewrite plugin fixes it
@srijken I’m going to test the dedup tomorrow and push out a release and finish up the server side stats
if you have any objections let me know :)
@niemyjski check
ok
how was everyones weekend?
@srijken @ejsmith
I noticed something with the .net client the other day and was wondering if you guys think we should fix it now before we release
if you take a look at the plugins.. the web api and mvc plugins run 100% of the time
and they set user info and do request info even if it’s already been set
so if you have an app that has both web api and mvc the web api stuff will run before mvc but will be taken out..
the issue with all of this is that we have a private info plugin that runs really early to set the user info to machine name..
then other things run and the web api plugin is towards the end that looks up the user info from the request
wondering if we need to make a service that is injected by mvc / web api for getting the user and falls back to environment.username
we’d need to define a interface and di helper to resolve the user identity
UserInfo GetUserIdentity(context)
IGetUserIdentity or something like that
what do you think
think it should fall back to environment.username if the interface doesn’t return anything?
I got it figured out :)
I think nuget is down
@ejsmith "I wanted to use your product in Xamarin solution(Android/iOS)... Which is provided via Pcl as far as I can understand... And it seemed to me like it's not storing unsent exceptions, so I looked at other solutions…"
with microsoft making xamarin free.. maybe it’s time we invest in a dedicated xamarin client that uses the pcl base..
so talking about offline storage for pal?
pcl
I think so I asked for clarificiation
I want to wait until RC2 comes out.
I think we can simplify things in the client then.
with the TFMs
yeah
TFM?
hey guys, I've been out of town for the past three days and didn't really get to read much on the PR I submitted
It’s all good :)
based on the feedback, I wonder if I should abandon it and let you guys discuss further, it seems like maybe you have larger plans
no pressure over here, we know you guys work on this in your free time and it’s greatly appreciated
Yeah, I think it was good to take a stab at it. I think there just needs to be some discussion around it.
We know we need to do it, just what’s the best way long term.
@moswald yeah, we are just trying to figure out what the best approach is and you got the discussion started and I think that is awesome. I think we just need to iterate from there.
we just want to make sure that we come up with a solution that we all agree with.
roger that - I'm just here to help ;)
That’s greatly appreciated
I’m testing the .net client for release and then I’ll take a look at the pr and add some feedback
I saw that there was activity on it this weekend I just was busy with family
@srijken seems to be working really good :D
@ejsmith when I get this user stuff done
I’m adding the ability to view the raw event json
I need it like every day
@srijken I’m taking a look into this
seems like when I click between two different errors multiple times I get a series of them
yeah, I think that is definitely useful
and should be quick
yeah
@ejsmith @srijken
it appears we are doing
hashCode = (hashCode * 397) ^ TotalPhysicalMemory.GetHashCode();
hashCode = (hashCode * 397) ^ AvailablePhysicalMemory.GetHashCode();
hashCode = (hashCode * 397) ^ ProcessMemorySize.GetHashCode();
hashCode = (hashCode * 397) ^ (ThreadName == null ? 0 : ThreadName.GetHashCode());
hashCode = (hashCode * 397) ^ (ThreadId == null ? 0 : ThreadId.GetHashCode());
which the memory one for process memory is changing by .1mb and causing it to not be deduplicated
wondering if thread id is changing it as well
hmm
total memory is fine
but I don’t think the memory and thread ones should be there
I’m seeing reference id interferring as it’s stored in a cookie
so it’s changing that on request info
should we remove cookies from the gethashcode logic too
?
no
why would we do that?
if the cookies are different, don’t we want to see them?
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?
yeah, that sucks
if we can skip that one
that would be good.
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
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.
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
I think removing those is reasonable
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
don’t know what you mean
look at the above log message
updated the unit test and it’s failing
c.UseLogger(new XunitExceptionlessLog(_writer));
:D
got awesome logging now in our client unit tests
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
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
@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
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
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
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
@frankebersoll https://github.com/sergeyt/karma-typescript-preprocessor/issues/30#issuecomment-99655328 looks like the tooling is starting to support typescript a bit better :)
Hi, reading
agree on removing those properties from gethashcode
locking thing.. it’s weird that it’s necessary?
concurrent queue should fix concurrency issues
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.
^^ What’s wrong with that?
except for the hash calculations
yeah
well those are all called concurrently
and they are all enqueued
when some of those should be ignored
that’s because the hashes don’t match up
yeah
look
so we must make sure they do match?
-2584673 all of those were enqueued and were the same number
same for the -1999577676
yeah there is something goofy going on
oh wait
it’s enqueueing them too often
yeah
idealy no lock would be good but if you look at it without one it’s chaos
can you add timestamps to the log output?
I’m pretty convinced it should work without the lock
the lock doesn’t fix the issue either right?
yeah we could do that by updating the xunit base class
xunitexceptionlesslog
it does part of the time
still fails randomly
yeah so there’s something else to it
yeah
nothing stood out to me
tried breaking it down
computer is slow
more random test failures? :-(
@niemyjski what’s the exact testcase you’re running?
I think I foudn it :P
hm it works for me
run it multiple times and it will fail
@ejsmith just with dedup on multithreaded
@srijken I can reproduce it everytime by triggering new mvc errors
just click it the same error multiple times (api post and api get links)
the hash mismatch is caused in .Data
I noticed that .Data implements its own GetHashCode(), should use the extensions one
GetCollectionHashCode()
hmm
ok
weird
data should be exactly the same on all of those
nice catch
that one will order the keys before calculating the hashcode
it’s not what’s causing the problem though
hmm ok
but you can delete a bunch of code, which is always nice
ok
@srijken have you figured out a good way to see how gethashcode is being miscalculated
also, does each line need to be (dashcode ^ 397) or just the whole thing on the return?
it’s what R# generates. I read up on why it did that, and it sounded like a good idea
397 is a fairly large prime number
yeah
determining what causes it is a painful job
yeah :(
weird thing is it seems to happen on that unit test ever few executions
it’s coming from the Modules collection inside Error
hmm
wonder if it has to do with the module id calculation
cause that changes
maybe modules need to be sorted?
if so that’s a pita
do we even care about module info
@ejsmith
too me just because a module is added or removed an error occurs doesn’t mean anything even on module load errors
it’s not the order
we reassign the module id on every ToExceptionless()
are they different?
I compared them with beyond compare and they were all the same on my machine (checked 6 dupes that came through) only thing that was different was the reference id
checking
not the ID either
id, date and reference id stuff was different when I checked on the raw json serverside
what ID? event ID or ModuleID?
event id
the testcase itself isn’t stable either.. Right now I have the same consistent hashcode, and it fails because it gets 8 where it expects 9
that bit is a timing problem
when it gets 2 where it expects 1, it’s a hashcode problem
I see my name was mentioned and there are like 100 messages?
yeah
so there are two different issues
@ejsmith yeah there were questions for you me and sander and working through them now
@ejsmith do you want me to merge in the EventStats into Foundatio Elasticsearch repository read only base?
yeah, that would be nice.
or a seperate class?
I think it would be good to have it as methods on the repo
ok
O
I’ll merge it in with models cause I need the terms stuff on our repo
ok, my search in .Modules was a stupid move. Conclusion now is that somehow the stacktrace is different
how
it’s the same stack trace :\
that’s what I don’t get
I get that it could be different in mvc due to maybe a race condition in handlers but crazy
@ejsmith there’s really no good way to do this in the base class:
.WithDateRange(utcStart, utcEnd, EventIndex.Fields.PersistentEvent.Date)
.WithIndices(utcStart, utcEnd, $"'{_eventIndex.VersionedName}-'yyyyMM");
.WithDateRange(utcStart, utcEnd, EventIndex.Fields.PersistentEvent.Date)
.WithIndices(utcStart, utcEnd, $"'{_eventIndex.VersionedName}-'yyyyMM");
hmf
getting quantum physics feelings right now
I’m inspecting where it’s probably failing
and it no longer fails
got it
Checking event: with hash: 754157865 1407249123 GetException: 766225261 - ILOffset 8 - NativeOffset87
Checking event: with hash: 752981631 1924808933 GetException: 217121131 - ILOffset 0 - NativeOffset87
Checking event: with hash: 754157865 1407249123 GetException: 766225261 - ILOffset 8 - NativeOffset87
Checking event: with hash: 754157865 1407249123 GetException: 766225261 - ILOffset 8 - NativeOffset87
Checking event: with hash: 754157865 1407249123 GetException: 766225261 - ILOffset 8 - NativeOffset87var error = context.Event.Data["@error"] as Exceptionless.Models.Data.Error;
context.Log.FormattedInfo(typeof(DuplicateCheckerPlugin), String.Concat("Checking event: ", context.Event.Message, " with hash: ", hashCode + " " + error.StackTrace.GetCollectionHashCode() +
" " + string.Join(", ", error.StackTrace.Select(x => x.Name + ": " + x.GetHashCode() + " - ILOffset " + x.Data["ILOffset"] + " - NativeOffset" + x.Data["NativeOffset"]))));
so.. now what?
@niemyjski can you try this change, see if it fixes the real-world problem you were seeing?
yeah
hashCode = (hashCode * 397) ^ (Data == null ? 0 : Data.GetCollectionHashCode(new[] { "ILOffset" }));
wonder if we should get rid of native offset too
now my mac is slow
that code goes in Method
wonder why the iloffset would be different on the same executing code
maybe it’s some kind of optimization thing
JIT and pre-JIT or something
C:\Code\Exceptionless.Net\Source\Shared\Models\Client\Data\EnvironmentInfo.cs(131): hashCode = (hashCode 397) ^ (Data == null ? 0 : Data.GetHashCode());
C:\Code\Exceptionless.Net\Source\Shared\Models\Client\Data\InnerError.cs(64): hashCode = (hashCode 397) ^ (Data == null ? 0 : Data.GetHashCode());
C:\Code\Exceptionless.Net\Source\Shared\Models\Client\Data\Method.cs(42): hashCode = (hashCode 397) ^ (Data == null ? 0 : Data.GetCollectionHashCode(new[] { "ILOffset" }));
C:\Code\Exceptionless.Net\Source\Shared\Models\Client\Data\Module.cs(51): hashCode = (hashCode 397) ^ (Data == null ? 0 : Data.GetHashCode());
C:\Code\Exceptionless.Net\Source\Shared\Models\Client\Data\Parameter.cs(36): hashCode = (hashCode 397) ^ (Data == null ? 0 : Data.GetHashCode());
C:\Code\Exceptionless.Net\Source\Shared\Models\Client\Data\RequestInfo.cs(100): hashCode = (hashCode 397) ^ (Data == null ? 0 : Data.GetHashCode());
C:\Code\Exceptionless.Net\Source\Shared\Models\Client\Data\SimpleError.cs(53): hashCode = (hashCode 397) ^ (Data == null ? 0 : Data.GetHashCode());
C:\Code\Exceptionless.Net\Source\Shared\Models\Client\Data\UserDescription.cs(43): hashCode = (hashCode 397) ^ (Data == null ? 0 : Data.GetHashCode());
C:\Code\Exceptionless.Net\Source\Shared\Models\Client\Data\UserInfo.cs(52): hashCode = (hashCode 397) ^ (Data == null ? 0 : Data.GetHashCode());
C:\Code\Exceptionless.Net\Source\Shared\Models\Client\Event.cs(82): hashCode = (hashCode 397) ^ (Data == null ? 0 : Data.GetHashCode());
C:\Code\Exceptionless.Net\Source\Shared\Models\Client\Data\InnerError.cs(64): hashCode = (hashCode 397) ^ (Data == null ? 0 : Data.GetHashCode());
C:\Code\Exceptionless.Net\Source\Shared\Models\Client\Data\Method.cs(42): hashCode = (hashCode 397) ^ (Data == null ? 0 : Data.GetCollectionHashCode(new[] { "ILOffset" }));
C:\Code\Exceptionless.Net\Source\Shared\Models\Client\Data\Module.cs(51): hashCode = (hashCode 397) ^ (Data == null ? 0 : Data.GetHashCode());
C:\Code\Exceptionless.Net\Source\Shared\Models\Client\Data\Parameter.cs(36): hashCode = (hashCode 397) ^ (Data == null ? 0 : Data.GetHashCode());
C:\Code\Exceptionless.Net\Source\Shared\Models\Client\Data\RequestInfo.cs(100): hashCode = (hashCode 397) ^ (Data == null ? 0 : Data.GetHashCode());
C:\Code\Exceptionless.Net\Source\Shared\Models\Client\Data\SimpleError.cs(53): hashCode = (hashCode 397) ^ (Data == null ? 0 : Data.GetHashCode());
C:\Code\Exceptionless.Net\Source\Shared\Models\Client\Data\UserDescription.cs(43): hashCode = (hashCode 397) ^ (Data == null ? 0 : Data.GetHashCode());
C:\Code\Exceptionless.Net\Source\Shared\Models\Client\Data\UserInfo.cs(52): hashCode = (hashCode 397) ^ (Data == null ? 0 : Data.GetHashCode());
C:\Code\Exceptionless.Net\Source\Shared\Models\Client\Event.cs(82): hashCode = (hashCode 397) ^ (Data == null ? 0 : Data.GetHashCode());
should we change all of those to GetCollectionHashCode?
yep
and dump DataDictionary.GetHashCode()
dump?
I changed all those to GetCollectionHashCode
the code inside DataDictionary, that can be removed
ok
“My understanding is that, when provided, the IL offset is simply mapped from the native offset using a table generated at JIT time (which may be an approximation due to optimizations). For the leaf native-frame, the native offset is where the exception was thrown while non-leaf native frames use the return address from the stack which may make it look like the exception was thrown by the instruction following the one where the exception actually happened."
hmm ok
so get rid of the equals and gethashcode overrides in the data
yeah
ok
wonderingi f we should leave it as it’s not hurting anything
this dedupe thing?
the equals and get hashcode on data dictionary
if you look on the data dictionary we are telling it to ignore tracelogs
hmf
complicated stuff
yeah
you changed it :D
lol
:)
so basically what we want is ignore
@trace on Error.Data
yeah I guess
can add that to an exclusion I guess
and delete that equals code
seems to all be working great!
just pass that key to .GetCollectionHashCode()
that pull request you submitted couldn’t be merged
yeah
yeah I noticed, I’ll fix it
first fix this stuff :)
right now I’m checking why we need the locking
pushed the changes :)
they fixed all the issues with mvc!!!
glad I tested before deploying heehe
_processed.Any() is on IEnumerable, so that’s not threadsafe
hmm
yeah
we want queue behavior for cleanup
for the rest we want ConcurrentDictionary behavior
really wish I could step into these extension methods or go to source but all I see is empty definitions
yep
_mergedEvents.FirstOrDefault() has the same issue
yeah
hmm what to do
well I think the issue is that it’s not found in the queue and then other code runs then it enqueues it between checks and the lock prevents that
the lock makes the whole thing threadsafe yeah
btw, what’s the difference between FormattedInfo and FormattedTrace?
couldn’t get the Trace to show up in the test runner
not sure
oh
LogLevel
and there is a min level in the unit tests of Debug
could update that in GetClient
to get rid of the lock, we would have to keep both a concurrentdictionary (for checking if we have them) and a concurrentqueue (for cleanup of the dictionary)
or CreateClient on the plugin tests
well if we are locking do we even need concurrentqueue anymore?
no
and is concurrentdictionary even in the pcl?
we could also do a reader/writer lock
what ever you think is best and easiest to maintain :)
:)
it’s not that much harder
@ejsmith this stuff is pretty specific to exceptionless
hitting some roadblocks
with the aggregations?
stuff like avg:somefield min:somefield, max:somefield
that shouldn’t be specific
i know
but we need access to the elastic index for alias name
so what is specific?
can share my screen quick
what do you mean alias name
can’t do that.
No generic way to inject the index on the context unless we add a constraint to the index with a <T> for the hell of it to auto inject it
then the date stuff is not generic but something we’d have to ahve
that’s only for terms tho
.WithDateRange(utcStart, utcEnd, EventIndex.Fields.PersistentEvent.Date)
.WithIndices(utcStart, utcEnd, $"'{_eventIndex.VersionedName}-'yyyyMM”);
is the biggest thing
you want to do smart date ranges
@niemyjski no ReaderWriterLock in PCL it seems, so just keep the lock the way it is?
yeah I guess
that is up to the user to pass in a filter and system filter just like any other thing in the repo
aggregations are on top of that.
wonder if we can get away with non concurrent queues but is it worth it? what might it introduce
use the exact same query builder stuff
yeah
ok
and, how much do you think we gain?
so object query as first param
yeah good idea :)
@srijken I’m not sure if anything but less chances to dead lock???
between there lock implementations and ours but I don’t see how that would happen with our locks being around everything
see first answer
that kinda suggests that it is in PCL?
oh where’s there’s a bunch of platforms
just leave it
could try a normal queue, and see if the tests + your recent problem are still OK?
really hope the new TFM stuff will make this simpler.
TFM?
is that missing an R in front? ;)
lol no
Target Framework Moniker
right
the stuff where you target an API surface area and all platforms that support that contract or higher just wokr.
and you don’t have to do stuff for each platform
@niemyjski merge conflict is fixed
yay
feel free to merge it in
can’t ;)
I’m fine either way no?
ugh build error
yeah
it’s complaining about some reference. How can that be, I just changed one cs file
@srijken you have write access to that repo, do you not see any options to merge?
yeah I do
can you kick that build off once again to see if that does anything?
exceptionless/Exceptionless.Net@85ee49c
can’t see how that can break anything
yeah
kicking it off again
fails again
been getting those type references for a while
MSBuild version is now 14, last time it succeeded it was at 12
hmm
that’s MSBuild 12
and that’s like yesterday
I updated some dependencies to try and get benchmarks.net to run appears there is an issue with with there latest version
yeah what the hell
C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(1098,5): error MSB3644: The reference assemblies for framework ".NETFramework,Version=v4.5,Profile=Client" were not found. To resolve this, install t
he SDK or Targeting Pack for this framework version or retarget your application to a version of the framework for which you have the SDK or Targeting Pack installed. Note that assemblies will be resolved from the Global Assembly
Cache (GAC) and will be used in place of reference assemblies. Therefore your assembly may not be correctly targeted for the framework you intend.
he SDK or Targeting Pack for this framework version or retarget your application to a version of the framework for which you have the SDK or Targeting Pack installed. Note that assemblies will be resolved from the Global Assembly
Cache (GAC) and will be used in place of reference assemblies. Therefore your assembly may not be correctly targeted for the framework you intend.
but the build you just triggered when you did the hashcode changes on master is also MSBuild 14, and that one doesn’t have this error
yeah
I think I broke it
how? :)
idk
so.. now what?
unless appveyor changed things..
well, MSBuild doesn’t change version numbers all by itself
what happens when you kick master?
these are in master
“these”?
I mean.. this one’s green: https://ci.appveyor.com/project/Exceptionless/exceptionless-net/build/3.4.1648
if you run it again, it should still be green
green or not
look at that commit and you can see in 43 that there are compiler related errors for system types
and that’s when the msbuild version changed :(
check
.Aggregations(agg => BuildAggregations(agg
.Terms("terms", t => BuildTermSort(t
.Field(term)
.Size(max)
.Aggregations(agg2 => BuildAggregations(agg2
.Min("first_occurrence", o => o.Field(ev => ev.Date))
.Max("last_occurrence", o => o.Field(ev => ev.Date)), fields)
), fields)
), fields)
.Terms("terms", t => BuildTermSort(t
.Field(term)
.Size(max)
.Aggregations(agg2 => BuildAggregations(agg2
.Min("first_occurrence", o => o.Field(ev => ev.Date))
.Max("last_occurrence", o => o.Field(ev => ev.Date)), fields)
), fields)
), fields)
it’s never easy is it?
not sure how we are going to do that
with numbers
nope :(
our numbers stats only support numbers and not dates
should be able to do a min and max aggregation on the date.
min:first_occurrence max:last_occurrence
and where would we put those results
we stick everything in numbers
and those are dates
what do you mean stick everything in numbers?
you mean the results are types as numbers?
yeah
type them as objects
could change those to be objects I guess
and convert them on our end
well the json will come down and it won’t matter
public async Task<NumbersTimelineStatsResult> GetNumbersTimelineStatsAsync(object query, IEnumerable<FieldAggregation> fields, TimeSpan? displayTimeOffset = null, int desiredDataPoints = 100) {
if (!displayTimeOffset.HasValue)
displayTimeOffset = TimeSpan.Zero;
// if no start date then figure out first event date
if (!filter.DateRanges.First().UseStartDate)
await UpdateFilterStartDateRangesAsync(filter, utcEnd).AnyContext();
utcStart = filter.DateRanges.First().GetStartDate();
utcEnd = filter.DateRanges.First().GetEndDate();
var interval = GetInterval(utcStart, utcEnd, desiredDataPoints);
var response = await Context.ElasticClient.SearchAsync<T>(CreateSearchDescriptor(query)
.SearchType(SearchType.Count)
.Aggregations(agg => BuildAggregations(agg
.DateHistogram("timelime", t => t
.Field(ev => ev.Date)
.MinimumDocumentCount(0)
.Interval(interval.Item1)
.TimeZone(HoursAndMinutes(displayTimeOffset.Value))
.Aggregations(agg2 => BuildAggregations(agg2, fields))
), fields))
.IgnoreUnavailable()
).AnyContext();
yeah that’s going to be fun...
to figure out what field to do the timeline on
guess I need to add a timeline aggregation with a few func’s eh?
side tracked on moving this over cause I need it for what I’m doing with counts per project on the repo
This message was deleted
@srijken
hm?
said they rolled out new vs2015 image
told me to use previous image
:(
unreal
I run VS2015 update 2
and it works
so..?
yeah
and we weren’t specifying a build image before
well I agree with running latest by default
otherwise a load of people never upgrade
yeah
I agree
there are some issues there that microsoft introduced
and until we drop .net 4.0 or move to standard lib I think they will be there
I’m off to bed
kk ty
the build thing, I’d switch back for now, wait what they come up with
and maybe have a branch that doesn’t have that image setting?
psuehd
pushed*
didn’t merge the PR yet, I’ll see tomorrow what happened ;)
ok
have a good night
var range = (query as IDateRangeQuery)?.DateRanges?.FirstOrDefault();
var interval = GetInterval(range?.GetStartDate() ?? DateTime.MinValue, range?.GetEndDate() ?? DateTime.UtcNow.AddHours(1), desiredDataPoints);
makes me wonder if that should just be a parameter
if you want fine grained intervals you call it
or specify a date range
might be really hard for us to figure out the right interval generically
var range = (query as IDateRangeQuery)?.DateRanges?.FirstOrDefault();
if (range == null || !range.UseDateRange)
throw new ArgumentOutOfRangeException(nameof(query), "Query must contain a valid date range.");
var interval = GetInterval(range.GetStartDate(), range.GetEndDate(), desiredDataPoints);
DateRange has a field property that we can use
but UseDateRange will return false if the start date is not greater than DateTime.MinValue so what if you want a range of all time?
wonder if well have issues with unlimited plans..
let me know if you want to look at this with me later