0x19 / goesl

Freeswitch Event Socket Library wrapper for Go
https://godoc.org/github.com/0x19/goesl
MIT License
127 stars 124 forks source link

Parse EOF #1

Closed MehSha closed 5 years ago

MehSha commented 9 years ago

Hello, i use the same code as your example server_playback but enable receiving events by calling conn.Send("events plain all"). but very often i get errors that are mostly Parse EOF. end if i select json format for event "event json all" i get unexpected end of json. also sometimes I get malformed MIME info. overall this made it impossible to use for listening to events. I tried to fork your work and change it but with no success, and because on any case of error you close connection, first error means server stops. note that the server and client and configuration works perfectly fine with nodejs esl client. what the hell this parse EOF means?

thanks in advance for yourhelp

0x19 commented 9 years ago

@MehSha hey!

Ok so I have no time at this moment to fix it but EOF means End Of File.

See this: https://github.com/0x19/goesl/blob/master/examples/client.go#L54

if !strings.Contains(err.Error(), "EOF") 

What I would do on your place is just not treat EOF as error. I will attach later on code that will do the same.

For malformed MIME. Can you please give me a little bit more info, panic, data, something as it's very hard like this to tell what's the problem.

Thanks!

htrendev commented 9 years ago

I have the same malformed MIME problem. Part of the JSON gets parsed as a header. It looks as if part of the text in the buffer is somehow skipped, which leads to incorrect parsing of the next message in the buffer and as a result an "unexpected end of JSON input" error occurs. Is it possible that the buffer is somehow overwritten/changed between the reads?

I can reproduce this 100%. It seems to happen when two events come at almost exactly the same time. The Content-Length header is then pre-pended with some JSON. The JSON part is in fact from the previous event in the stream. It looks like this:

map[{"Event-Name":["RE_SCHEDULE","Core-UUID":"5394f610-9504-4d11-a8e7-86f60fd13331","FreeSWITCH-Hostname":"fs1.example.com","FreeSWITCH-Switchname":"fs1.example.com","FreeSWITCH-IPv4":"10.10.10.10","FreeSWITCH-IPv6":"::1","Event-Date-Local":"2015-09-16 18:07:03","Event-Date-GMT":"Wed, 16 Sep 2015 16:07:03 GMT","Event-Date-Timestamp":"1442419623317552","Event-Calling-File":"switch_scheduler.c","Event-Calling-Function":"switch_scheduler_execute","Event-Calling-Line-Number":"71","Event-Sequence":"620500","Task-ID":"1","Task-Desc":"heartbeat","Task-Group":"core","Task-Runtime":"1442419643"}Content-Length: 608] Content-Type:[text/event-json]]

I have verified with a packet capture that the headers are correctly formatted and that the JSON is valid.

I also tried ignoring the "unexpected end of JSON input" error as suggested, but after that no more events get processed.

MehSha commented 9 years ago

any fix, or any hint to fix it is much appreciated.

htrendev commented 9 years ago

If that helps, I have also tested with https://github.com/fiorix/go-eventsocket and it parses all messages correctly. Maybe there is a hint in this code, which may help you identify the problem?

0x19 commented 9 years ago

@MehSha and @htrendev thx on this finding! I will really do my best to get on this as soon as possible. Will try to get some time scheduled for this today or tomorrow.

avbdr commented 5 years ago

offered patch is fixing a problem