Hi Yuan, Well, the first 3 segments I already have running … I’m working on the „removal of sigletons“ … and yes … that’s a huge undertaking ;-)
I didn’t look too deeply into the current state of IoTDB as when I last worked for Timecho, I kept on being worried about datanode becoming fatter and fatter. If now all is externalized as modules, that makes my life easier. And yes … in most deployments I worked on (Deploying IoTDB to Ignition and CtrlX) I didn’t like that the ConfigNode and DataNode were running in the same VM but still using Network communication to communicate with each other … Serializing, sending, parsing in both directions. I wanted to update IoTDB do do direct inner-vm calls but whenever I brought this up in the past, it was discarded as not being needed. I can whip up a PR, that handles the Java 17 and Jakarta update. Chris Von: Yuan Tian <[email protected]> Datum: Dienstag, 31. März 2026 um 02:55 An: [email protected] <[email protected]> Betreff: Re: [DISCUSS] Singleton-Free IoTDB? Java 17? Jakarta? Hi Chris, Personally, I am in favor of the following points: - Bumping the base Java version to Java 17 - Switching from the JavaX to the Jakarta namespace - Switching to the develop branch However, regarding the switch from Singletons to Dependency Injection, I feel this would be a massive undertaking. We currently rely on a large number of singletons, and refactoring all of them would consume a significant amount of the community's energy while bringing relatively limited benefits. Regarding *replacing the MQTT support with one based on an MQTT client rather than a Broker*: I don't think a direct replacement is necessary. The current MQTT implementation is already decoupled as an independent plugin. You could implement your client-based approach as a new plugin under the external-service package, and we could simply let users choose which MQTT implementation they want to use via configuration. As for *stripping the DataNode into its bare essentials*: Have you outlined what constitutes these "bare essentials"? In my view, apart from the code related to Pipe and Subscription, the rest of the current DataNode essentially belongs to the core read/write functionalities, especially since protocol layers like MQTT and REST have already been extracted. Regarding *allowing inner-VM communication between ConfigNode and DataNode*: Actually, I have a similar plan to develop an embedded version of IoTDB called embedded-iotdb (conceptually similar to SQLite). This plan involves completely removing Thrift and ratis (which would make embedded-iotdb much leaner) and replacing the communication between CN and DN with direct function calls. I wonder if your goal aligns with this plan? Best regards, --------------------- Yuan Tian On Fri, Mar 27, 2026 at 4:18 PM Christofer Dutz <[email protected]> wrote: > Hi all, > > As you know, I have brought up several topics repeatedly over the last few > years. > Things that I personally require to continue using IoTDB. > > > * > Living the base-java-version to Java 17 > * > Switching from JavaX to Jakarta namespace > * > Switching from Singletons to Dependency Injection (Spring) > * > Developing on „develop“ and not „master“ (We voted for that years ago but > never did the switch) > > As recently all of them have been denied or ignored, I have created a > personal fork where I applied these changes. > > So now I’m asking … is there interest in this from side of the Project? If > yes, I’m happy to whip up a PR (Even if it’s most probably a HUGE one). If > not, I’ll probably keep on working on my fork and keeping it closed but > stop going the extra mile for making it able to go back into IoTDB and > fully go nuts about it, forming it fully into what I would like it to be > like. > > > * > Replacing the MQTT support with one based on an MQTT client and not an > MQTT Broker. > * > Stripping DataNode into it’s bare essentials > * > Moving all current DataNode extensions into separate plugins. > * > Allowing inner-VM communication between config- and data-node. > > Chris >
