Xiangdong Huang created IOTDB-1353:
--------------------------------------
Summary: Add thrift-based cluster DBA API implementation (like
NodeTool)
Key: IOTDB-1353
URL: https://issues.apache.org/jira/browse/IOTDB-1353
Project: Apache IoTDB
Issue Type: Sub-task
Components: Cluster
Reporter: Xiangdong Huang
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).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
