cl-stomp issueshttps://gitlab.common-lisp.net/cl-stomp/cl-stomp/-/issues2022-11-15T15:41:31Zhttps://gitlab.common-lisp.net/cl-stomp/cl-stomp/-/issues/3CL-STOMP:ACK does not actually work (patch inside).2022-11-15T15:41:31ZetaCL-STOMP:ACK does not actually work (patch inside).The `ACK` method inside this package doesn't actually work. I've attached a patch to fix it here, since it wasn't possible to fork the project due to GitLab project limits (?). (See the patch commit message for more information.)
[0001-...The `ACK` method inside this package doesn't actually work. I've attached a patch to fix it here, since it wasn't possible to fork the project due to GitLab project limits (?). (See the patch commit message for more information.)
[0001-Make-CL-STOMP-ACK-actually-work-following-the-1.2-sp.patch](/uploads/9624996f0161cb11725d8dbdf703e835/0001-Make-CL-STOMP-ACK-actually-work-following-the-1.2-sp.patch)https://gitlab.common-lisp.net/cl-stomp/cl-stomp/-/issues/2Patch to add support for heart-beat2020-09-05T23:48:24ZAnthony GreenPatch to add support for heart-beatI am using stomp with ActiveMQ, and needed heart-beat support. Please consider merging my changes, which are available here:
https://github.com/atgreen/cl-stomp/commit/b6a4f3972ba6dbae196a28917e9098eb7ed4ebe5
I couldn't figure out how...I am using stomp with ActiveMQ, and needed heart-beat support. Please consider merging my changes, which are available here:
https://github.com/atgreen/cl-stomp/commit/b6a4f3972ba6dbae196a28917e9098eb7ed4ebe5
I couldn't figure out how to fork and create a merge request on gitlab, so you'll have to grab it from github.
Thanks!https://gitlab.common-lisp.net/cl-stomp/cl-stomp/-/issues/1Cl-stomp:start loop may crash with a type error2019-04-04T15:14:41ZDirk EßerCl-stomp:start loop may crash with a type errorNot sure, whether this is a recent development with usocket, but `cl-stomp:start` will crash in
(let ((sock #| ===> #| (car #| <=== |# (usocket:wait-for-input socket :timeout 1))))
(when sock
(let ((newbuf (append ...Not sure, whether this is a recent development with usocket, but `cl-stomp:start` will crash in
(let ((sock #| ===> #| (car #| <=== |# (usocket:wait-for-input socket :timeout 1))))
(when sock
(let ((newbuf (append recvbuf (receive conn))))
(setf recvbuf (process-receive-buffer conn newbuf) ...
since `wait-for-input` returns the value passed as first argument under certain circumstances. The problem can be solved by either passing `(list socket)` as first argument (instead of just `socket`), or adding the keyword argument `:ready-only t` to the call. Given the behaviour of `usocket:wait-for-input` it might even be feasible to just get rid of the `car`, but I didn't look into that carefully enough, so I'd go with one of the other options.
Let me know, if you want me to cook up a pull request. I was able to reproduce this with the example program ("example.lisp") by just calling the `start` function.
The value
#<USOCKET:STREAM-USOCKET {1004B5D743}>
is not of type
LIST
[Condition of type TYPE-ERROR]
Backtrace:
0: ((:METHOD CL-STOMP:START (CL-STOMP::CONNECTION)) #<CL-STOMP::CONNECTION {10042407D3}> :USERNAME NIL :PASSCODE
NIL) [fast-method]
1: ((FLET "WITHOUT-INTERRUPTS-BODY-4" :IN SB-THREAD::INITIAL-THREAD-FUNCTION-TRAMPOLINE))
2: ((FLET SB-THREAD::WITH-MUTEX-THUNK :IN SB-THREAD::INITIAL-THREAD-FUNCTION-TRAMPOLINE))
3: ((FLET "WITHOUT-INTERRUPTS-BODY-1" :IN SB-THREAD::CALL-WITH-MUTEX))
4: (SB-THREAD::CALL-WITH-MUTEX #<CLOSURE (FLET SB-THREAD::WITH-MUTEX-THUNK :IN SB-THREAD::INITIAL-THREAD-FUNCTION-TRAMPOLINE) {6A41CFB}> #<SB-THREAD:MUTEX "thread result lock" owner: #<SB-THREAD:THREAD "..
5: (SB-THREAD::INITIAL-THREAD-FUNCTION-TRAMPOLINE #<SB-THREAD:THREAD "stomp-subscribe" RUNNING {1003E57D63}> NIL #
<FUNCTION (LAMBDA NIL :IN START) {100350D5AB}> (#<SB-THREAD:THREAD "stomp-subscribe" RUNN..