ce-rust / cerk Goto Github PK

with #![deny(missing_docs)]

https://doc.rust-lang.org/1.9.0/book/documentation.html

cerk/src/kernel/config.rs:12:3

warning: derive helper attribute is used before it is introduced
--
  | --> cerk/src/kernel/config.rs:12:3
  | \|
  | 12 \| #[serde(untagged)]
  | \|   ^^^^^
  | 13 \| #[derive(Deserialize, Serialize)]
  | \|          ----------- the attribute is introduced here
  | \|
  | = note: `#[warn(legacy_derive_helpers)]` on by default
  | = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
  | = note: for more information, see issue #79202 <https://github.com/rust-lang/rust/issues/79202>

Currently, mosquitto_client is compiled with the WITH_TLS flag set to no. This means users of mosquitto-client-wrapper are not able to open secure connections.
ce-rust/mosquitto-client-wrapper#9

This means that the MQTT Mosquitto Port is currently not able to support TLS.

The new release management introduced in #80 could easily be automated by just pushing a tag to master.

The version bump command would look something like cargo workspaces version custom "0.2.8" --no-git-push --allow-branch="*release*" --yes

Harmonize the error handling by using anyhow for error handling in all components.

the example needs to be fixed and reactivated in the pipeline

https://buildkite.com/ce-rust/cerk/builds/643#0181e289-4c94-4925-9eb2-2babc5b45ed4

the example needs to be fixed and reactivated in the pipeline

https://buildkite.com/ce-rust/cerk/builds/643#0181e289-4c86-43b2-9dfa-144d15a9610f

In some special scenarios, the Kernel can be blocked forever in case the channel from the Kernel to the port is full.

Example (with channel size 30):

Port A: Pushed 31 incoming CloudEvents to the Kernel -> The port is blocked now.
Kernel: Pushes 31 outgoing CloudEvents to Port A -> Kernel is blocked
-> Deadlock

Current workaround

Use the health check. With the help of the health check port, this scenario can be identified, and the router can be restarted. This is okay if the delivery guarantee at-least-once is used.

Implement port which connects to an open UNIX socket and listens on CloudEvents.

Currently, the router routes messages to ports.
However, most messaging protocols know the concept of channels.
It would be nice if the routing does not only allow a port destination but also a port+channel destination.

Example:
We have an AMQP Port that is connected to a RabbitMQ Service called port A.
Port A has a configuration of two exchanges: Exchange 1 and exchange 2.
Messages can be routed to port A.
Port A currently forwards the messages to all configured exchanges (1&2) on RabbitMQ.
It would be nice to be able to select the destination port AND channel, e.g., port A & exchange 1.

Workaround:
One port per channel group that should be addressable has to be configured.
This means that there is an overhead of multiple TCP connections to the same service.

For the example this means: Port A with exchange 1 and port B with exchange 2 have to be configured.

For the cerk_port_mqtt_mostquitto we are using the mosquitto_client library. Unfortunately, the published version does not support the latest version of libmossquitto even though there is an open pull request to add support for a while.

Because of that, we are using not the version of the package published on crates.io but the patched one (see #77 (comment)). This prevents us from publishing the cerk_port_mqtt_mostquittoon crates.io

There are different ways to approach this issue:

• wait until stevedonovan/mosquitto-client#10 is merged
• fork mosquitto_client and republish it on crates.io
• use autogenerated binding directly

The MQTT Port currently only supports QoS 0 (At Most Once Delivery Guarantee). The reason is that the used MQTT library doesn't allow the delay of the PUBACK message until the message is processed (see eclipse/paho.mqtt.c#522).

We tried to patch the Cand rust library (see eclipse/paho.mqtt.c@master...ce-rust:feat/ack-after-processing and eclipse/paho.mqtt.rust@master...ce-rust:feat/ack-after-processing-0.8.0).
This patch allowed us to block in the message callback till the message was successfully delivered over another port.

But then we run into another problem: The C library uses the same threads and mutex for all the connections. In the case there are multiple MQTT Ports, the blocking of the message handler results in the blocking of the other connections => Dead Lock.

We then tried to fork the process before opening the connections. This way the different ports would not share the same threads and mutex. We tried to implement that in the port crate (see https://github.com/ce-rust/cerk/tree/feat/mqtt-port-subprocess) but unfortunately, forking the process in that stage of the router lifecycle results in unexpected behavior (see https://thorstenball.com/blog/2014/10/13/why-threads-cant-fork/).

Possible solutions:

1. find MQTT library that supports the delay of PUBACK
2. write a MQTT library that supports the delay of PUBACK
3. implement a Scheduler component for the router that is not based on threads but on processes. (requires major changes in cerk, e.g. BrokerEvent must be serializable.

https://afonsopacifer.github.io/open-source-checklist/