Using the JVM QuestDB client on a Raspberry PI 3B?

Community
,
1

I currently have a Raspberry Pi 3 Model B Plus Rev 1.3 attached to a device (Heatpump in this case) and I’m using some custom software (based on MiNifi) to send the measurements to a very old InfluxDB.
I’m moving to QuestDB so I have rewritten my code (Kotlin) to use the questdb-client 1.0.1 instead.

Works great on my laptop and it fails with this error on the armv7l based PI 3.

java.lang.UnsatisfiedLinkError: 'void io.questdb.client.std.Vect.memset(long, long, int)'
	at io.questdb.client.std.Vect.memset(Native Method)
	at io.questdb.client.std.Unsafe.<clinit>(Unsafe.java:516)
	at io.questdb.client.std.Numbers.<clinit>(Numbers.java:1839)
	at io.questdb.client.Sender$LineSenderBuilder.address(Sender.java:604)
	at ThermiaToQuestDB_main.<init>(ThermiaToQuestDB.main.kts:107)

I found that the root cause is that the Java questdb-client actually has a native code part which does not include the binary part for the armv7l cpu.

What is the recommended way of handling this?

  • Is there a clean JVM client library (i.e. without any native/jni parts)?
  • Use a different client to send the data? If so which one?
  • Submit a change for the client code to also include this very old cpu type?
  • Something else?

Thanks.

Niels

2

Hi @nielsbasjes ,

We don’t currently have a ‘thin’ client, we rely on a port of QuestDB’s custom networking stack, which is indeed native code.

We are still compatible with Influx v1 and v2 connectors, but are about to replace the wire protocol with something more efficient.

In this case, you may need to build the client from source, with a new CMAKE entry that sets set(CMAKE_SYSTEM_PROCESSOR armv7). The database itself runs correctly on RPi 4/5, which are armv8, and the client library should support JDK 11.

I have a RPi 3+ lying around so may be able to check it out later this week, if you are unable to make progress. If you are able to build it correctly, we can upstream the change, though we may not be able to add it to CI if there are no armv7 runners.

3

Thanks for clarifying this.
About the native part
I understand the Pi 3B+ is old and support for it is being reduced across the board (Github, KMP, and also this project).
I have essentially the same custom code (getting my solar data) running on a PI4 (i.e. 64 bit) and that works fine.

Having parts implemented native in your server side I kinda understand, but why also at the client side?
From my perspective having a non-native (i.e. pure Java) client would make things a lot simpler for building, testing and deployment.
This would then also immediately have support for both all old (like the ARMV7L) and new CPUs (like the RISC-V) which was the idea behind Java from the start.

About alternative routes
What simple protocol will remain which I can use to send the data towards my server? Is there a http/rest/text based protocol (like ILP) that you will keep? I can then write a simple HTTP client to post the records that way.

4

From my perspective having a non-native (i.e. pure Java) client would make things a lot simpler for building, testing and deployment.

I agree, we just haven’t gotten round to maintaining a ‘thin’ client. Previously, the client was integrated with the main QuestDB distribution, we only recently split it into a standalone binary.

We try to minimise GC and heap allocations, hence the way the current client is written, but swapping out the network stack or porting the C# client should not be a huge lift, just something I couldn’t commit to immediately.

What simple protocol will remain which I can use to send the data towards my server? Is there a http/rest/text based protocol (like ILP) that you will keep? I can then write a simple HTTP client to post the records that way.

We are keeping ILP, you will just get better performance if you use the new protocol, which is WebSockets based. We also accept CSV import (/imp), SQL inserts over HTTP (/exec), Parquet import (copy to server, read from disk), PG Wire inserts.

5

Clear.
In that case I’m going to do a very basic HTTP implementation that simply does ILP.
Thanks!

6

No problem. Back in the day when I had my own platform, ILP/HTTP did not exist and I wanted error feedback that ILP/TCP didn’t support, so I leveraged /imp route - it worked well for my data rates.