tormaroe / cl-nats

NATS client for Common Lisp
MIT License
8 stars 3 forks source link

"Random" <<- [-ERR Parser Error] (missing newline?) #8

Open cherrymud opened 7 years ago

cherrymud commented 7 years ago

I haven't debugged deeply, but I've run into a problem where 50% or more of the time, my lisp cl-nats client dies with:

end of file on #<FLEXI-STREAMS:FLEXI-IO-STREAM {1003662D93}>

Turning on -DV on gnatsd (0.9.6), it seems that a newline might not be added between the CONNECT and SUB commands?:

[32348] 2017/02/02 23:29:45.542711 [TRC] 127.0.0.1:54894 - cid:46 - ->> [CONNECT {"name":"","lang":"LISP","version":"0.1.1","verbose":true}SUB help3 1]
[32348] 2017/02/02 23:29:45.542749 [ERR] 127.0.0.1:54894 - cid:46 - Error reading from client: invalid character 'S' after top-level value
cherrymud commented 7 years ago

Here's another example from the logs:

[32348] 2017/02/02 23:29:43.751174 [DBG] 127.0.0.1:54890 - cid:44 - Client connection created
[32348] 2017/02/02 23:29:43.871112 [TRC] 127.0.0.1:54890 - cid:44 - ->> [SUB help3 1CONNECT {"name":"","lang":"LISP","version":"0.1.1","verbose":true}]
[32348] 2017/02/02 23:29:43.871144 [TRC] 127.0.0.1:54890 - cid:44 - <<- [OK]
[32348] 2017/02/02 23:29:43.874980 [TRC] 127.0.0.1:54890 - cid:44 - <<- [-ERR Unknown Protocol Operation]
[32348] 2017/02/02 23:29:43.875041 [ERR] 127.0.0.1:54890 - cid:44 - Error reading from client: Client Parser ERROR, state=0, i=0: proto='"\r"...'
[32348] 2017/02/02 23:29:43.875051 [TRC] 127.0.0.1:54890 - cid:44 - <<- [-ERR Parser Error]
[32348] 2017/02/02 23:29:43.875070 [DBG] 127.0.0.1:54890 - cid:44 - Client connection closed
tormaroe commented 7 years ago

Thank you for letting me know. I'm not actively working on this project, and I would not consider it production ready as it stands. Feel free to send a pull request though if you're able to fix the issue.

cherrymud commented 7 years ago

I'll experiment a bit and see what I can turn up. Could still be an environment issue on my side.

cherrymud commented 7 years ago

I've made a repo with example code and some notes here: https://github.com/cherrymud/msgtest

cherrymud commented 7 years ago

By putting a sleep between nats:make-connection and nats:subscribe, it seems to avoid the problem. It looks like (force-output stream) in nats-write might not be completing the write before the next nats-write function call is made.

cherrymud commented 7 years ago

For the moment, it seems like:

(defvar conn (nats:make-connection))
(nats:wait-for-connection conn)
...

avoids the problem. Seems like I was trying to subscribe and publish on a connection that wasn't established yet.