Redis server v=2.8.4
org.clojure/clojure "1.6.0"
com.taoensso/carmine "2.8.0"
)
When I try below code, I do not see any printouts from handlers.
I.e., I expect to see "Channel match..." and "Pattern match..." whenever I publish matching key value pairs. But no printouts.
(ns my-app (:require [taoensso.carmine :as car :refer (wcar)]))
(def server1-conn {:pool {}
:spec {:host "localhost" :port 6379 :timeout 4000
}})
(def listener
(car/with-new-pubsub-listener (:spec server1-conn)
{"foobar" (fn f1 [msg] (println "Channel match: " msg))
"foo*" (fn f2 [msg] (println "Pattern match: " msg))}
(car/subscribe "foobar" "foobaz")
(car/psubscribe "foo*")))
;;; Confirmed subscribe through 'redis-cli monitor' at this point
(defmacro wcar* [& body] `(car/wcar server1-conn ~@body))
(wcar* (car/publish "foobar" "Hello to foobar!"))
;;; Confirmed publish through 'redis-cli monitor' at this point
For 1: Both @foobar and @foo will start with a value of 0 in your code there. If you're seeing anything other than 0, try restart Redis &/or your REPL to clear any lingering state.
For 2: the :timeout option was causing your Pub/Sub connection to close after 4000 milliseconds (4 seconds). You probably don't want a :timeout when using Pub/Sub.
Sorry - that's my mistake: @foobar and @foo should both have value 1 here, not zero. This is because each is getting one message. If you watch the println output you'll see:
For 2
In the case of timeout, probably connection should be re-opened automatically for subscribe listeners. Now I understand what's going on but when I first hit this problem, it was so strange because I didn't have any issues with the connection spec until that moment.
To me, the current pub/sub machinery of Carmine has a mismatch problem between 'how it looks' and 'how it works'. So I have to dig into source code to figure out how to use. (maybe it is just me?)
(I saw some tickets on pub/sub, so probably you may have some improvement ideas in the future)
What about alternative design which shows hints about messages?
The current design provides messages of the form: [<source> <channel-id> <message-content>].
You can check and/or route by the <source>, which will be "message" or "pmessage" for "publish" command messages. The Redis docs go into detail about this format.
So if you want to ignore subscribe/unsubscribe information, just ignore messages whose <source> is "subscribe" or "unsubscribe". Does that make sense?
In the case of timeout, probably connection should be re-opened automatically for subscribe listeners.
There are use-cases for a Pub/Sub listener + timeout with the current behaviour. If you don't want the Pub/Sub connection to close, you can leave off the :timeout option. I'll mod the Pub/Sub docstrings to make it clearer that you probably don't want a :timeout option there - appreciate the suggestion :-)
What about alternative design which shows hints about messages?
The current design provides messages of the form: |[
]|.
You can check and/or route by the ||, which will be "message"
or "pmessage" for "publish" command messages. The Redis docs
http://redis.io/topics/pubsub go into detail about this format.
So if you want to ignore subscribe/unsubscribe information, just
ignore messages whose || is "subscribe" or "unsubscribe". Does
that make sense?
I had read Redis docs after your explanation (which Carmine does not
work the way I expected), and I knew it. My suggestion is providing a
clear declarative style handler construction can be better than
providing documentation (in this case Redis doc to use Carmine).
In the case of timeout, probably connection should be re-opened
automatically for subscribe listeners.
There are use-cases for a Pub/Sub listener + timeout with the current
behaviour. If you don't want the Pub/Sub connection to close, you can
leave off the :timeout option. I'll mod the Pub/Sub docstrings to make
it clearer that you probably don't want a :timeout option there -
appreciate the suggestion :-)
Does that help?
That raises a curiosity; Without timeout option, if there is an
exception (like one from a bogus message) does the listener still works
for later valid 'publish' messages?
That raises a curiosity; Without timeout option, if there is an
exception (like one from a bogus message) does the listener still works
for later valid 'publish' messages?
Sure, the listener traps + logs exceptions, so the listener will continue to work.
That raises a curiosity; Without timeout option, if there is an
exception (like one from a bogus message) does the listener still
works
for later valid 'publish' messages?
Sure, the listener traps + logs exceptions, so the listener will
continue to work.
ptaoussanis
commented
9 years ago 
ozjongwon
commented
9 years ago
The example handlers in the doc do not get called. Is this known issue? (if yes, sorry please close this)