Clojurians Log v2

Looks like it is caused by the addition of meta. I added some print statements and got this:

(m/? (let [id 1] (m/sp (sql/format {:select [:*] :from :table :where [:= :id id]}))))
:k :select
:x [:*]
:meta {:tag clojure.lang.PersistentVector}
:k :tag
:k clojure.lang.PersistentVector

I had to add {:ignored-metadata [:tag]} to honeysql/format

@hoertlehner do you have a repro for the timbre issue ?

@leonoel Sorry, I dont. What I did is replace timbre with telemere in functions that caused missionary to fail, and that solved the issue. What I do remember is that there is at least part of the logging that is happening synchronous, namely the lookup of the hostname. And in this call timbre is blocking, and that was interferring with missionary. I doubt that timbre will get fixed, as the successor library telemere is already out, this is why I did not care. But my codebase is 150.000 clojure lines, and there is still a lot of timbre logging going on. I am gradually introducing missionary to my codebase, and what I can easily do is not replace any existing timre logging, and in case this error reappears, then save detailed stacktraces at least. Would this be helpful?

yes a stacktrace would definitely help

@hoertlehner but what do you mean by similar problem? It was a ClassCastException? Otherwise what was similar about it? I have never had any issue between timbre and missionary except that one time i made a bad reduction that terminated early due to an error. What timbre doesnt like is if the thread is interrupted while its looking up the hostname

I just run into this too. :ignored-metadata didn't work in my case, not sure why, ended up doing (vary-meta select-clause (constantly nil)).

(defn foo [jdbc select]
    (jdbc/execute! jdbc
      (sql/format
        {:from   :products
         :select (vary-meta select (constantly nil))}
        ;; {:ignored-metadata [:tag]} ; still err
        )))

  (m/? (m/sp (foo a-jdbc [:*])))

I filed an issue https://github.com/leonoel/missionary/issues/119

I have Noticed a problem similar to the one on honeysql with both datahike and timbre. Datahike should be fixed now. Timbre is not working. It would be great if @leonoel could elaborate as to how/why this would happen. It must be something that happens when inside a missionary task this external libraries use thread blocking that somehow interfers with missionary thread management.

there may be something wrong with your graph setup, can you reproduce the bug without http://deck.gl ?

Hmm, that's going to be tricky as there are no errors but http://deck.gl seems to have an issue with the subsequent viewport events when I consume the mbx with signal/stream. I was wondering if somehow it could discard the event object and it's used by http://deck.gl. (It shouldn't imo, but since it's going from react's uncontrolled to controlled there might be something that goes on with that event). It's not important enough to figure out now. I've resorted to just an ap loop and racing on the mbx's and that seems to work for my use-cases for now. Thanks.