We have a pluggable broker interceptor,
> I think we need to trigger some event as bellow:
- [ ] Client connected
- [ ] Client disconnected
- [ ] Consumer subscribe
- [ ] Consumer unsubscribe
- [ ] Producer publish
- [ ] Message delivered
- [ ] Message acked
For these events, the broker intercept
This is a great topic, thanks for starting the discussion Mattison.
The PIP only mentions topic events right now--I think we should
include (or plan to include) metadata related events, too.
I proposed a similar feature in April 2021. There was good discussion
then that is relevant now [0].
I th
Hi mattison,
> For this part, I think we need to discuss. Do we create a specific event
> class or use properties in json format?
I think String value would be enough for most cases.
IMHO, these system event is mostly for administrators, so the data should be
readable.
> Maybe the better way
Hi, Dave Fisher
> These bother me too. Producer and consumers can accomplish the same use cases
> in their application logic.
>
> Any notification mechanism must be very lightweight. What is the implantation
> plan?
Agree with you.
I think we just need to record some system internal event tha
Hi, Haiting Jiang
>> CompletableFuture trigger(SystemEventMessage message);
>
> Maybe `record` make more sense?
+1
>> SystemEventMessageBuilder properties(Map properties);
>>
>> SystemEventMessageBuilder addProperty(String key, Object value);
>
> How to handle the serialization and dese
Sent from my iPhone
> On Jan 5, 2022, at 8:10 PM, Haiting Jiang wrote:
>
>
>> CompletableFuture trigger(SystemEventMessage message);
>
> Maybe `record` make more sense?
>
>> SystemEventMessageBuilder properties(Map properties);
>>
>> SystemEventMessageBuilder addProperty(String key,
> CompletableFuture trigger(SystemEventMessage message);
Maybe `record` make more sense?
> SystemEventMessageBuilder properties(Map properties);
>
> SystemEventMessageBuilder addProperty(String key, Object value);
How to handle the serialization and deserialization if the value type i
