[BUILD-UNSTABLE]: Job 'IoTDB/IoTDB-pip-new/master [master] [336]'

[Apache Jenkins Server]

BUILD-UNSTABLE: Job 'IoTDB/IoTDB-pip-new/master [master] [336]':

Check console output at "https://ci-builds.apache.org/job/IoTDB/job/IoTDB-pip-new/job/master/336/;>IoTDB/IoTDB-pip-new/master
 [master] [336]"

Re: Move Jenkins notifications to another list

[Haonan Hou]

https://github.com/apache/iotdb/pull/11029
Done.

Thanks,
Haonan

On 2023/09/04 03:13:22 Gaofei Cao wrote:
> strongly +1, it's really disturbing for many [BUILD-UNSTABLE] emails..
> 
> Best,
> Gaofei
> 
> Christofer Dutz  于2023年8月24日周四 15:04写道：
> >
> > Hi,
> >
> > If we have any build emails else than for “master”, I would agree to have 
> > them on other lists.
> >
> > For the ones going to master, the problem is much more the flaky tests.
> > We should put more effort into making sure build failures are indeed errors 
> > that need working on.
> > With a build that randomly fails and people have become used to simply 
> > clicking on “re-run failed tests” a CI sort of looses a big portion of what 
> > it should provide.
> >
> > Chris
> >
> >
> > Von: Haonan Hou 
> > Datum: Donnerstag, 24. August 2023 um 04:28
> > An: dev-iotdb 
> > Betreff: Move Jenkins notifications to another list
> > Hi,
> >
> > I think the daily Jenkins build notification is a lot bit noisy. It may be 
> > better to move it to another list.
> > Such as notificati...@iotdb.apache.org 
> > .
> >
> > Any idea?
> >
> > Best,
> > Haonan Hou
> 

Re: Move Jenkins notifications to another list

[Gaofei Cao]

strongly +1, it's really disturbing for many [BUILD-UNSTABLE] emails..

Best,
Gaofei

Christofer Dutz  于2023年8月24日周四 15:04写道：
>
> Hi,
>
> If we have any build emails else than for “master”, I would agree to have 
> them on other lists.
>
> For the ones going to master, the problem is much more the flaky tests.
> We should put more effort into making sure build failures are indeed errors 
> that need working on.
> With a build that randomly fails and people have become used to simply 
> clicking on “re-run failed tests” a CI sort of looses a big portion of what 
> it should provide.
>
> Chris
>
>
> Von: Haonan Hou 
> Datum: Donnerstag, 24. August 2023 um 04:28
> An: dev-iotdb 
> Betreff: Move Jenkins notifications to another list
> Hi,
>
> I think the daily Jenkins build notification is a lot bit noisy. It may be 
> better to move it to another list.
> Such as notificati...@iotdb.apache.org 
> .
>
> Any idea?
>
> Best,
> Haonan Hou

AW: [DISCUSS] Configuration of the MQTT subsystem

[Christofer Dutz]

Hi all,

At first I thought we were bundling an MQTT client with a MQTT broker.
But it turns out that when enabling the MQTT subsystem we actually start a 
broker and attach our stuff internally.
This completely binds us to the Moquette MQTT broker and it’s impossible to use 
IoTDB in an existing MQTT system.

I would propose to refactor this part to make use of an MQTT client with the 
option to start a Moquette MQTT server, if no other MQTT broker is available.

What do you folks think?

Chris


Von: Christofer Dutz 
Datum: Freitag, 1. September 2023 um 14:46
An: dev@iotdb.apache.org 
Betreff: [DISCUSS] Configuration of the MQTT subsystem
Hi folks,

I’m currently working hard on implementing a SparkplugB PayloadFormatter that 
would allow us to directly consume a SparkplugB mqtt stream.

However have I noticed two things:

  1.  The current PayloadFormatter interface, doesn’t pass the topic to the 
format method (in Sparkplug the device Id is located in that)
  2.  The current config option enable_mqtt_service does two things
 *   It starts a local MQTT broker
 *   It registers as client to the MQTT broker configured in the settings

I worked around the Problem in 1) by Adding a PayloadFormatterV2 interface 
which extends the PayloadFormatter, that adds one method:

List format(String topic, ByteBuf payload);

Then I extended the MPPPublishHandler to check if the handler instance 
implements V2 or not.
If it’s a V2 it calls the new method and passes the topic along, if not, it 
uses the old one. This way no compatability problems should occur.

However I would never use a broker like the moquette broker in a large scale 
production environment. Here I’d probably go for HiveMQ or alike.
Unfortunetely we currently can’t enable the MQTT consumer stuff without 
starting the broker.

I think we need 2 settings here.

Chris