Details
-
Sub-task
-
Status: Closed
-
Major
-
Resolution: Fixed
-
None
-
None
-
None
Description
Now, IoTDB provides interactives as following:
1. thrift API for users, which allows users to read and write data. The cluster module and the single node module have the same API.
2. thrift sync API for edge devices, which allows edge devices to upload files to the cloud server.
3. JMX-based DBA API in the single node module. It allows users to monitor the system status, change some settings and even stop the service.
4. JMX-based DBA API in the cluster module. It allows users to know how the cluster looks like, e.g., given a time series, users can know which nodes are responsible for the time series.
Now, I'd like to create a thrift-based API (called cluster API) that has the same functionality with the No.4 API.
It is because:
- Comparing with No.3, the API in No.4 is mainly "read data", rather than "change data". But sometimes, something like querying the data partition is helpful.
- That is, it is more like a programming API, rather than a maintenance API.
- Besides, JMX has many restrictions (For example, if the hostname and hosts file are incorrect, it can not be enabled)
- JMX programming is a little complex than thrift.
- JMX-based API can not be enabled in GraalVM and similar images.
More considerations:
- Why not put the APIs into No.1?
Sadly we cannot, as it will break the current modularized design. We will have to let the server module depends on thrift-cluster.
- Why not migrate all JMX-based API to thrift based?
It may happen in the future, but it is too early to make the decision now. JMX has its advantages, e.g., there are many tools supporting it. Besides, for dangerous things (i.e., some APIs that are used to control the server), we'd better put it in a safe place.
- The port?
I'd like to use port 6567 (as normal API port is 6667).