Clojurians Log v2

Thank you @hiredman so I have to somehow split the message in the application or would e.g. Sente do it for me? Would increasing the size e.g. to 1 MB have some negative consequences?

I have updated the issue. From looking into get-sch-adapter in taoensso.sente.server-adapters.aleph the implementation doesn't seem to accept any options that could be consumed by websocket-connection in aleph.http. So I probably could increase the max-frame-payload a bit but would have to first patch the Sente server adapter for Aleph.

I wonder, how do other people solve this? Do people split everything in the implementation to fit into a frame/ the message? Do people use other adapters or just maybe Aleph directly? As you can see, I am a bit lost. 🙂

I doubt most people send frames that large

The websocket protocol has a frame splitting mechanism built, but I don't recall how that is used

Do you think people generally send less data over websockets or just use smaller messages and send more of them?

I guess I don't really know. A websocket connection can send one frame at a time, so if you are sending a large frame, other frames will be backed up behind it

But 64k isn't that big

Our websocket usage at work is largely for timely small message delivery (it is part of a chat server), anything large (images, etc) is served over http

As in AJAX?

We have an app, where you can manipulate multiple elements on a worksheet e.g. by Copy&Paste - this potentially creates quite a bit of churn and the messages get proportionally large-ish. E.g. manipulating ~ 100 elements creates messages above 64k since every element has a color, position, size, content etc.

We use the AJAX route for files, e.g. pictures, videos, PDFs etc.

Yeah ajax

Ok, thank you for the comments and tips

the docs say that defrecord fields can have type hints, but this does not seem to work? even with type hints on the fields, when i try to use it elsewhere it still gets reflected as java.lang.Object

is there a way around this?

Hi everyone, i am trying to add influxdb’s v2 support to riemann. My changes are here: https://github.com/chhetripradeep/riemann/pull/1/files But when i try to run this code, it gives error https://gist.github.com/chhetripradeep/c5df294c5e5ff4fb2019136765d15209 I am unable to figure out the cause of it.

my first guess would be that your post-datapoint returns a string when it catches an exception (instead of printing it), which might not be the return type whatever is calling it expects?

I see. thank you for the pointers. i am new to clojure. let me try.

try putting println instead of str and see what happens

i tried replacing the str with println in post-datapoint func but still see the same stacktrace.

Try adjusting your dependency like this

[com.influxdb/influxdb-client-java "2.2.0" :exclusions [com.squareup.retrofit2/retrofit]]

Sure trying

Still the same error. Thank you for continuous help. Much appreciated.

that's really weird. so from what i see this error is caused at this line: https://github.com/square/retrofit/blob/fbf1225e28e2094bec35f587b8933748b705d167/retrofit-converters/scalars/src/main/java/retrofit2/converter/scalars/ScalarRequestBodyConverter.java#L25 except that method signature no longer exists in okhttp: https://github.com/square/okhttp/pull/5132 so i figured you might be adding a too recent version of the influxdb dependency thus causing a version collision... this seems to be happening too, since lein deps :tree tells me

[org.influxdb/influxdb-java "2.8"] -> [com.squareup.retrofit2/retrofit "2.3.0"]
 overrides
[com.influxdb/influxdb-client-java "2.2.0"] -> [com.squareup.retrofit2/converter-gson "2.9.0"] -> [com.squareup.retrofit2/retrofit "2.9.0"]
 and
[com.influxdb/influxdb-client-java "2.2.0"] -> [com.squareup.retrofit2/converter-scalars "2.9.0"] -> [com.squareup.retrofit2/retrofit "2.9.0"]
 and
[com.influxdb/influxdb-client-java "2.2.0"] -> [com.influxdb/influxdb-client-core "2.2.0"] -> [com.squareup.retrofit2/retrofit "2.9.0"]

Consider using these exclusions:
[com.influxdb/influxdb-client-java "2.2.0" :exclusions [com.squareup.retrofit2/retrofit]]

[org.influxdb/influxdb-java "2.8"] -> [com.squareup.okhttp3/okhttp "3.9.1"]
 overrides
[com.influxdb/influxdb-client-java "2.2.0"] -> [com.squareup.retrofit2/converter-gson "2.9.0"] -> [com.squareup.retrofit2/retrofit "2.9.0"] -> [com.squareup.okhttp3/okhttp "3.14.9"]
 and
[com.influxdb/influxdb-client-java "2.2.0"] -> [com.squareup.retrofit2/converter-scalars "2.9.0"] -> [com.squareup.retrofit2/retrofit "2.9.0"] -> [com.squareup.okhttp3/okhttp "3.14.9"]
 and
[com.influxdb/influxdb-client-java "2.2.0"] -> [com.influxdb/influxdb-client-core "2.2.0"] -> [com.squareup.okhttp3/logging-interceptor "4.7.2"] -> [com.squareup.okhttp3/okhttp "4.7.2"]
 and
[com.influxdb/influxdb-client-java "2.2.0"] -> [com.influxdb/influxdb-client-core "2.2.0"] -> [com.squareup.retrofit2/retrofit "2.9.0"] -> [com.squareup.okhttp3/okhttp "3.14.9"]
 and
[com.influxdb/influxdb-client-java "2.2.0"] -> [com.influxdb/influxdb-client-core "2.2.0"] -> [com.squareup.okhttp3/okhttp "4.7.2"]

Consider using these exclusions:
[com.influxdb/influxdb-client-java "2.2.0" :exclusions [com.squareup.okhttp3/okhttp]]

[org.influxdb/influxdb-java "2.8"] -> [com.squareup.okhttp3/logging-interceptor "3.9.1"]
 overrides
[com.influxdb/influxdb-client-java "2.2.0"] -> [com.influxdb/influxdb-client-core "2.2.0"] -> [com.squareup.okhttp3/logging-interceptor "4.7.2"]

Consider using these exclusions:
[com.influxdb/influxdb-client-java "2.2.0" :exclusions [com.squareup.okhttp3/logging-interceptor]]

[com.influxdb/influxdb-client-java "2.2.0"] -> [com.google.code.gson/gson "2.8.5"]
 overrides
[com.influxdb/influxdb-client-java "2.2.0"] -> [io.gsonfire/gson-fire "1.8.4"] -> [com.google.code.gson/gson "2.8.6"]

Consider using these exclusions:
[com.influxdb/influxdb-client-java "2.2.0" :exclusions [com.google.code.gson/gson]]

https://mvnrepository.com/artifact/com.influxdb/influxdb-client-java/2.2.0 https://mvnrepository.com/artifact/org.influxdb/influxdb-java/2.8 there must be a version mismatch in there somewhere that causes your error

you can try upgrading influxdb-java to 2.21 (latest) and see what happens... or use an old version of influxdb-client-java which has "closer" dependency versions to those of influxdb-java 2.8

Interesting. Nice find @vale sure

Thank you so much @vale That did solved the problem. 🎉 Great debugging.

sure thing~ maven dependency resolution can do that to you... then again if you did bump an existing dependency that might make your pr hard to merge since the change might break other code...

I agree, I will try my best to verify on my end that the existing dependency bump doesn’t break influxdb v1 integration. Thank you once again for your help.

no problem! good luck

defrecord fields are always Object (or primitive long/double)

so, there is no way around that if you are trying to access the fields directly