These are chat archives for exceptionless/Discuss

22nd
Jun 2015
Lukas Wöhrl
@woehrl01
Jun 22 2015 13:08
Hi! Im using JsonConvert.SerializeObject(error.Target) and new ErrorBuilder(JsonConvert.DeserializeObject<Error>(log)) to Pipe some exceptions from client which don't have an Internet connection. Since my update to 2.x those exceptions are all Grouped to the same stack even so they have different Messages. The Stacktrace is also missing in 2.x. Do you have any idea what the problem could be? All these things worked perfectly fine under 1.x
When I open the "Extended Data" page I have a huge field named "_@error" which seems to have the missing stacktrace
Blake Niemyjski
@niemyjski
Jun 22 2015 13:11
Can you paste a snippet of the code here
Everything is an event now and that could be the issue
Lukas Wöhrl
@woehrl01
Jun 22 2015 13:11
saving is this step:

var error = e.ToExceptionless();

string path = Process.GetCurrentProcess().MainModule.FileName;

var version = FileVersionInfo.GetVersionInfo(path);

error.AddObject(version, "ExeVersion");

string errorAsString = JsonConvert.SerializeObject(error.Target);
var log = new ExceptionLogEntry
{
Log = errorAsString,
OccurenceTime = DateTime.Now
};
_dao.Create(log);

and the sending is doing this:
string log = _dao.First();
var error = JsonConvert.DeserializeObject<Error>(log);
var builder = new ErrorBuilder(error);
builder.Submit();
Blake Niemyjski
@niemyjski
Jun 22 2015 13:13
Why not let us handle submission?
Where is dao writing these to?
Lukas Wöhrl
@woehrl01
Jun 22 2015 13:14
the dao is storing them in the database
Blake Niemyjski
@niemyjski
Jun 22 2015 13:14
And what determines when they are sent
Lukas Wöhrl
@woehrl01
Jun 22 2015 13:15
the reason we can't use exceptionless directly are restrictions on the network. not every client is allowed to connect to the internet
so we have an agent which polls the database table end sends them
Blake Niemyjski
@niemyjski
Jun 22 2015 13:16
Ah
So give me a few minutes (waking up)
Lukas Wöhrl
@woehrl01
Jun 22 2015 13:16
take your time ;)
Blake Niemyjski
@niemyjski
Jun 22 2015 13:16
But there's a much better way to do this now :)
Lukas Wöhrl
@woehrl01
Jun 22 2015 13:20
by the way, another reason to do this, is that we can are also able to send exceptions which occure in c++. The agent assembls an exceptionless error from parsing a errorreport from a cpp library and sends those over the wire into exceptionless. (so no need to update the clients when we change the parsing ;) )
I know that all of this is easier with 2.x ;)
Lukas Wöhrl
@woehrl01
Jun 22 2015 13:27
by the way: the Event Type is error and Error type is unknown
Blake Niemyjski
@niemyjski
Jun 22 2015 13:51
So I think your best thing to do would be to implement your own queue
and get rid of all of your custom logic
I'd open our source and take a look at DefaultEventQueue
Then remove the process logic and the enqueue should just store the event to your database..
then remove the process logic :)
Lukas Wöhrl
@woehrl01
Jun 22 2015 13:53
hm, sad. because it worked perfectly fine with 1.x :-/
Blake Niemyjski
@niemyjski
Jun 22 2015 13:53
we'll you were doing kind of a massive hack around 1.x
in 2.0 everything is dependency injected
so this would be really clean
and work a lot better
with no overhead of serialzing to disk.. it would go straight to the database.
serializer.Serialize(events);
so you'd just need to implement EnQueue and then call dao.Save(serializer.Serialize(ev)); and your done
one line of code
Then on your logic that pulls....
you could do the same thing but implement process that pulls it from the database and deserializes it to type of event and then post it :)
you should be able to do this in about 20 lines of code or less (With the class)
for both sides of it
if you need some help quick I could jump on a meeting with you and help you quick
Lukas Wöhrl
@woehrl01
Jun 22 2015 13:57
ok, I'll have a look into this. I hoped I could do this without requiring to change something on the clients ;)
Blake Niemyjski
@niemyjski
Jun 22 2015 13:57
second thing you could do is create a relay server
and make no changes
Lukas Wöhrl
@woehrl01
Jun 22 2015 13:58
any idea what could be the root of the problem?
Blake Niemyjski
@niemyjski
Jun 22 2015 13:58
string errorAsString = JsonConvert.SerializeObject(error.Target);
var log = new ExceptionLogEntry
{
Log = errorAsString,
OccurenceTime = DateTime.Now
};
_dao.Create(log);
Lukas Wöhrl
@woehrl01
Jun 22 2015 13:59
just for information purposes ;)
Blake Niemyjski
@niemyjski
Jun 22 2015 13:59
your giving it the error.Target as the error string instead of passing in the whole event
cleanest / safest / fastest way to do this would be with what I said
it takes away any serialization issues
and makes for code reuse on the puller and submission clients
not submission but clients in general
Lukas Wöhrl
@woehrl01
Jun 22 2015 14:00
jep, I think this would be the cleanest to use the serialisation of 2.x
I used error.Taget, because this is of type Error. because error is just the ErrorBuilder.
which has the "ExceptionlessClient" which I didn't want to serialize ;)
Blake Niemyjski
@niemyjski
Jun 22 2015 14:03
public class DatabaseEventQueue : IEventQueue {
    private readonly IJsonSerializer _serializer;

    public DatabaseEventQueue(IJsonSerializer serializer) {
        _serializer = serializer;
    }

    public void Dispose() {
    }

    public void Enqueue(Event ev) {
        var log = new ExceptionLogEntry {
            Log = _serializer.Serialize(ev),
            OccurenceTime = DateTime.Now
        };

        _dao.Create(log);
    }

    public async Task ProcessAsync() {}

    public void SuspendProcessing(TimeSpan? duration = null, bool discardFutureQueuedItems = false, bool clearQueue = false) {}
}
that would be the very basic
thing is.. how do you handle it' when your database is offline
you'd need some handling around that.. if you don't mind saving it to our storage.. you would just copy our defaulteventqueue and make the changes in process queue to save it to your database and then turn off the client when there is an error.
Yeah, that is true
hey
so I was just thinking
Lukas Wöhrl
@woehrl01
Jun 22 2015 14:06
If the database is offline, I currently would just ignore storing the exception
Blake Niemyjski
@niemyjski
Jun 22 2015 14:06
I might even have a simplier approach for you
do you know what instances don't have internet connection?
ok
Lukas Wöhrl
@woehrl01
Jun 22 2015 14:08
no, I don't know this dependes. And because I want the same behaviour on every client. I simply store always to database. No need for a special behaviour handling
Blake Niemyjski
@niemyjski
Jun 22 2015 14:08
ok
I think the method I showed you would be the best
Then you'd just need to register your queue with our client :)
Lukas Wöhrl
@woehrl01
Jun 22 2015 14:10
I need to try this out. I hoped I could do a very easy fix (on the agent side), without requering updating the clients
Blake Niemyjski
@niemyjski
Jun 22 2015 14:10
        client.Configuration.Resolver.Register<IEventQueue, DatabaseEventQueue>();
@woehrl01, well I think the issue is you are not using our serializer
we'll append _@ if we can't deserialize it
so you should always be using our serializer which you can get an instance of via our dependency injection
just do
DependencyResolver.Default.GetJsonSerializer();
or better yet: client.Configuration.Resolver.GetJsonSerializer();
Lukas Wöhrl
@woehrl01
Jun 22 2015 14:12
i used json.net because that what was used in 1.x internally
Blake Niemyjski
@niemyjski
Jun 22 2015 14:13
also if you wanted a cleaner way to add that exe path object.. I'd recommend using a plugin: http://exceptionless.com/how-to-add-a-plugin-to-affect-events-in-exceptionless/
Yes, but we have custom serializer settings :)
Lukas Wöhrl
@woehrl01
Jun 22 2015 14:14
good hint!
:D
Blake Niemyjski
@niemyjski
Jun 22 2015 14:14
so
one thing that you may want to consider doing
is creating a proxy end point
where you just popup a http layer that forwards everything
so you wouldn't have to touch any client code or server code..
and it would just report to us
and everything would just work
the client only has three api end points it talks to so you'd just have to define those and pass those requests on
Lukas Wöhrl
@woehrl01
Jun 22 2015 14:16
so, I'm not able to avoid redoing the seralisation/deserialisation stuff. I will redo the things as you proposed
Blake Niemyjski
@niemyjski
Jun 22 2015 14:17
okay, you could also just inject our serializer and use our serializer with your existing code
if it's working for you that's all that matters. but there is a better way :)
Lukas Wöhrl
@woehrl01
Jun 22 2015 14:17
yeah, but this would still require me to change the clients ;)
no problem with that, but I hoped I could do the changes without breaking the backwards compatibility
because is still use 1.x stuff agent + client
only the server is 2.x yet
Blake Niemyjski
@niemyjski
Jun 22 2015 14:20
hmm
Lukas Wöhrl
@woehrl01
Jun 22 2015 14:20
thats the weird thing. that with just changing the server to 2.x the exceptions are not properly shown. haven't changed the clients yet
Blake Niemyjski
@niemyjski
Jun 22 2015 14:20
yeah
Lukas Wöhrl
@woehrl01
Jun 22 2015 14:20
and the agent
Blake Niemyjski
@niemyjski
Jun 22 2015 14:20
one second
So you have to support both 1x and 2.x clients still?
Lukas Wöhrl
@woehrl01
Jun 22 2015 14:22
jep, because I can't update all clients at once
I can do this only customer wise
Blake Niemyjski
@niemyjski
Jun 22 2015 14:23
we'll crap
..
Lukas Wöhrl
@woehrl01
Jun 22 2015 14:23
:smile:
Blake Niemyjski
@niemyjski
Jun 22 2015 14:24
your going to have issues wit hthis approach cause your not storing the client version in the database
so how do you know what one to deserialize to
Lukas Wöhrl
@woehrl01
Jun 22 2015 14:26
good point, need to think about this, too :smile:
ok, but as I know now that I need to make a bigger change. I will do it as proposed. as with 2.x this is much easier. thanks for your help!
Blake Niemyjski
@niemyjski
Jun 22 2015 14:29
Are you hosting with us or self hosting
Lukas Wöhrl
@woehrl01
Jun 22 2015 14:29
self hosting
Blake Niemyjski
@niemyjski
Jun 22 2015 14:29
and are you deploying your dequeue pulling at each client?
and a database at each or what?
Lukas Wöhrl
@woehrl01
Jun 22 2015 14:32
the setup is like this: Each customer as a database, if a fat client throws an error (C# or C++) those are just stored into the database. a separate service which has connection to the internet and the database table polls the table and sends them to the exceptionless instance together with a tag to separate the different customers
Blake Niemyjski
@niemyjski
Jun 22 2015 14:33
we'll
Lukas Wöhrl
@woehrl01
Jun 22 2015 14:33
so the database and the fat clients are able to be in a restricted network without internet access.
Blake Niemyjski
@niemyjski
Jun 22 2015 14:33
I wonder if it would be easier to just setup a proxy or something on client that don't have an internet connection
I get what you are doing just thinking..
I'd add a column to your databases for versioning
Lukas Wöhrl
@woehrl01
Jun 22 2015 14:35
there is another reason we have this setup. on some customers we are not allowed to even access the internet. so the support is able to have look at exceptions via the database
Blake Niemyjski
@niemyjski
Jun 22 2015 14:36
and then do this queue implementation and then on your dequeue look at that column and figure out if it's v1 or v2 and then do the right thing
You could just deploy an exceptionless instance inside each of these customers orgs and be done :)
Lukas Wöhrl
@woehrl01
Jun 22 2015 14:37
:smile:
Blake Niemyjski
@niemyjski
Jun 22 2015 14:39
I'll be here. I'm going to go get some breakfast
if you have any questions just shoot an im
other than this issue. how is everything working out for you?
Lukas Wöhrl
@woehrl01
Jun 22 2015 14:39
thanks! enjoy your meal!
everything good so far. thx! just this small issues :)
Lukas Wöhrl
@woehrl01
Jun 22 2015 14:56
just found out that is used the Newtonsoft json.net serializer, and the Exceptionless 1.x deserializer. (namespaces mistake ;) )
Blake Niemyjski
@niemyjski
Jun 22 2015 15:04
yeah
we internalize each one
Lukas Wöhrl
@woehrl01
Jun 22 2015 15:06
I suppose there are different serialiser settings in the 1.x branch. ;)
Blake Niemyjski
@niemyjski
Jun 22 2015 15:06
might be
not 100% sure
might have to just rip out the 1.x serializer settings and then have two different serializers that you use
shouldn't be to hard
Lukas Wöhrl
@woehrl01
Jun 22 2015 15:06
I'll test this in the next days ;) thank you very much for your help!
Blake Niemyjski
@niemyjski
Jun 22 2015 15:06
no problem
Lukas Wöhrl
@woehrl01
Jun 22 2015 15:07
have a nice day!
Blake Niemyjski
@niemyjski
Jun 22 2015 15:08
you too