27 lines
1.6 KiB
Markdown
27 lines
1.6 KiB
Markdown
Preview Feature: Support for Version 2 Bridge Design
|
|
|
|
- Introduction of Action with a new 'connector' concept
|
|
|
|
- In the original Bridge v1 design, each connector was exclusively tied to a single bridge.
|
|
This design prioritized error isolation and performance but posed challenges for users setting up multiple bridges to the same service.
|
|
For instance, setting up 10 bridges to a single Kafka cluster required the same configuration to be repeated for each bridge.
|
|
|
|
- The revamped Action design provides more flexibility and better scalability:
|
|
- Users have the option to either share a connector across multiple bridges or retain it exclusively for one bridge, as in v1.
|
|
- For the majority of data bridges, sharing a connector among too many bridges might lead to performance degradation but avoids
|
|
overloading the external system with too many connections if the number of bridges is very high.
|
|
- In some cases, specific data bridges always utilize dedicated connections, even when the connector is shared.
|
|
Right now these are:
|
|
- Kafka Producer
|
|
- Azure Event Hub Producer
|
|
|
|
- Management of Connectors
|
|
- Connectors can now be managed separately, bringing in more flexibility.
|
|
- New API endpoints have been introduced under the `/connectors` path for connector management.
|
|
- Actions can be managed via the `/actions` endpoint.
|
|
|
|
- Limitations in e5.3.1
|
|
|
|
- Currently, only the Kafka and Azure Event Hub producer bridges have been upgraded to the action design.
|
|
- The action feature is accessible through config files and HTTP APIs. However, it's not yet available on the dashboard UI.
|