Fork me on GitHub
#clojure
<
2021-05-15
>
Adam Kalisz00:05:02

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?

Adam Kalisz00:05:29

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.

Adam Kalisz00:05:56

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. 🙂

hiredman00:05:39

I doubt most people send frames that large

hiredman00:05:17

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

Adam Kalisz00:05:41

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

hiredman00:05:04

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

hiredman00:05:17

But 64k isn't that big

hiredman00:05:19

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

Adam Kalisz00:05:31

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.

Adam Kalisz00:05:35

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

Adam Kalisz00:05:41

Ok, thank you for the comments and tips

valerauko15:05:06

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

Alex Miller (Clojure team)17:05:23

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

Alex Miller (Clojure team)17:05:14

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

valerauko15:05:16

is there a way around this?

Pradeep Chhetri15:05:31

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.

valerauko15:05:52

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?

Pradeep Chhetri15:05:04

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

valerauko15:05:09

try putting println instead of str and see what happens

👍 2
Pradeep Chhetri16:05:49

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

valerauko16:05:47

Try adjusting your dependency like this

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

Pradeep Chhetri16:05:27

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

valerauko16:05:56

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]]

valerauko16:05:30

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

Pradeep Chhetri16:05:54

Interesting. Nice find @UAEH11THP sure

👍 2
Pradeep Chhetri16:05:39

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

💯 2
valerauko16:05:10

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...

Pradeep Chhetri16:05:57

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.

valerauko16:05:10

no problem! good luck

🙇 2