9 Jan
2015
9 Jan
'15
11:01 p.m.
Hi,
I'm using evapi to emit JSON blobs to share presence event transitions
with a TCP client:
loadmodule "evapi"
modparam("evapi", "workers", 4)
modparam("evapi", "bind_addr", "0.0.0.0:8010")
modparam("evapi", "netstring_format", 0)
if($hdr(Event) eq 'dialog' && $cl > 0) {
$xml(u=>doc) = $rb;
$var(state) =
$xml(u=>xpath:/di:dialog-info/di:dialog/di:state/text());
evapi_relay("{ \"type\": \"state_transition\",
"
"\"sip_user\":
\"$(fU{s.escape.common})\", "
"\"sip_domain\":
\"$(fd{s.escape.common})\", "
"\"state\": \"$var(state)\"
}");
}
Every once in a while, however, my consumer service's JSON.parse()
throws a parsing exception. There seems to be no particular pattern.
When I investigated the actual string being sent, I found two objects
concatenated:
JSON parsing exception: SyntaxError: Unexpected token {
Raw received string was: { "type": "state_transition",
"sip_user":
"6789540671", "sip_domain": "sip.evaristesys.com",
"state": "" }{
"type": "state_transition", "sip_user":
"6789540671", "sip_domain":
"sip.evaristesys.com", "state": "" }
Any ideas as to why this might happen?
Thanks,
-- Alex
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
10 Jan
10 Jan
1:37 a.m.
Hello,
it looks like two jsons one after other, which is what happens over tcp
stream. If you write them at the slow pace and the consumer reads
constantly, then it is likely that it will read one document at a time.
If you write faster than consumer reads, then it will get them
accumulated in the tcp buffer, one after the other. The consumer needs
to be a stream parser and detect when there first json document ends,
process it, then read the next one.
We do the same for sip, that's why the code for reading sip over tcp is
rather complex, with lots of states (given there can be any kind of
broken sip message).
Alternative for evapi is to use the netstring encoding, which is easier
to read a json document at once, because the size is given first.
Cheers,
Daniel
On 09/01/15 22:01, Alex Balashov wrote:
Hi,
I'm using evapi to emit JSON blobs to share presence event transitions
with a TCP client:
loadmodule "evapi"
modparam("evapi", "workers", 4)
modparam("evapi", "bind_addr", "0.0.0.0:8010")
modparam("evapi", "netstring_format", 0)
if($hdr(Event) eq 'dialog' && $cl > 0) {
$xml(u=>doc) = $rb;
$var(state) =
$xml(u=>xpath:/di:dialog-info/di:dialog/di:state/text());
evapi_relay("{ \"type\": \"state_transition\",
"
"\"sip_user\":
\"$(fU{s.escape.common})\", "
"\"sip_domain\":
\"$(fd{s.escape.common})\", "
"\"state\": \"$var(state)\"
}");
}
Every once in a while, however, my consumer service's JSON.parse()
throws a parsing exception. There seems to be no particular pattern.
When I investigated the actual string being sent, I found two objects
concatenated:
JSON parsing exception: SyntaxError: Unexpected token {
Raw received string was: { "type": "state_transition",
"sip_user":
"6789540671", "sip_domain": "sip.evaristesys.com",
"state": "" }{
"type": "state_transition", "sip_user":
"6789540671", "sip_domain":
"sip.evaristesys.com", "state": "" }
Any ideas as to why this might happen?
Thanks,
-- Alex
--
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
10:39 p.m.
Daniel,
Thank you for that clarification. I had considered that this might be a
possible reason. However, the consumer is Node.js, so I figured that the
high-level data read event that it presents might deal with this problem
to provide chunked output to the implementor that was equal to the
chunks sent.
Thanks, I will find a way to deal with it on the client side, and I'm
sorry for prematurely assuming that it was some sort of bug.
-- Alex
On 01/09/2015 06:37 PM, Daniel-Constantin Mierla wrote:
Hello,
it looks like two jsons one after other, which is what happens over tcp
stream. If you write them at the slow pace and the consumer reads
constantly, then it is likely that it will read one document at a time.
If you write faster than consumer reads, then it will get them
accumulated in the tcp buffer, one after the other. The consumer needs
to be a stream parser and detect when there first json document ends,
process it, then read the next one.
We do the same for sip, that's why the code for reading sip over tcp is
rather complex, with lots of states (given there can be any kind of
broken sip message).
Alternative for evapi is to use the netstring encoding, which is easier
to read a json document at once, because the size is given first.
Cheers,
Daniel
On 09/01/15 22:01, Alex Balashov wrote:
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
Hi,
I'm using evapi to emit JSON blobs to share presence event transitions
with a TCP client:
loadmodule "evapi"
modparam("evapi", "workers", 4)
modparam("evapi", "bind_addr", "0.0.0.0:8010")
modparam("evapi", "netstring_format", 0)
if($hdr(Event) eq 'dialog' && $cl > 0) {
$xml(u=>doc) = $rb;
$var(state) =
$xml(u=>xpath:/di:dialog-info/di:dialog/di:state/text());
evapi_relay("{ \"type\": \"state_transition\",
"
"\"sip_user\":
\"$(fU{s.escape.common})\", "
"\"sip_domain\":
\"$(fd{s.escape.common})\", "
"\"state\": \"$var(state)\"
}");
}
Every once in a while, however, my consumer service's JSON.parse()
throws a parsing exception. There seems to be no particular pattern.
When I investigated the actual string being sent, I found two objects
concatenated:
JSON parsing exception: SyntaxError: Unexpected token {
Raw received string was: { "type": "state_transition",
"sip_user":
"6789540671", "sip_domain": "sip.evaristesys.com",
"state": "" }{
"type": "state_transition", "sip_user":
"6789540671", "sip_domain":
"sip.evaristesys.com", "state": "" }
Any ideas as to why this might happen?
Thanks,
-- Alex
3609
days inactive
3610
days old
2 comments
2 participants
participants (2)
-
Alex Balashov -
Daniel-Constantin Mierla