Is MOP still being developed

[gmatej]

It seems that after issue: "MoP Proxy seems redundant, introduces unnecessary complexity" the development kinda stopped ?

Anybody uses it in a production environment ?

BR

Matej

[oneby-wang]

Me, but I strongly recommend you not using it.

I had encountered several critical production bugs. With my private fixes, our production MoP seems running properly now, but my solution differs from MOP's architecture, so I can't contribute it back to the community.

[gmatej]

The problem is the PING mechanism and the proxying approach right ? .Also not sure they can handle many connections this way...

[oneby-wang]

The problem is the PING mechanism and the proxying approach right ?

Not only this problem, The key problem is in MoP Proxy. Netty MqttEncoder and MqttDecoder can't be share across multiple connections within different mqtt versions.

For example, if two direct connections: connectionA and connectionB, connect to MoP broker1, assume they are all redirected to MoP Proxy broker2 using the same shared connection: connectionC.

Then connectionC is established using the first connection params, which I think is not reasonable.

What's worse? The connectionC stores mqtt version in its ChannelContext, and the mqtt version would be modified every time when connectionA or connectionB communicate with connectionC. Just Imagine the concurrent issue, sometimes we will use mqtt3.1.1 decoder to decode mqtt5.0 payload, and error occurs.

What other issues does MoP have? We can't close shared connection when error occurs, because closing one shared connection will lead many direct mqtt connections to close, and MoP follows this principle. If the server encounters some errors, we can't bring back these errors back to the client(or not so easily), so the client may not know these errors(using qos0), or may get some errors or timeout(using qos1).

I had suffered a lot to make MoP run properly(seems properly), and I would recommend you not using it.

Also not sure they can handle many connections this way...

MoP can handle many connections. I ran some stress tests and verified it. But as mentioned before, MoP is not so stable.

[tsturzl]

It makes me really sad to see things still in this state. I had also put a substantial amount of effort into making it work properly, and had gotten fairly close but ultimately gave up because there was no interest from the maintainers who seem to actively deny that these issues even exist. I had gone so far as to report the issue through Stream Native support after validating that the issues also existed on their paid SaaS offering. This at least got some response that led to a hotfix but it still never improved the core issues, and ultimately the massive amount of issues we had and the poor experience we had with Stream Native (including talking to their sales team) led our team to rework Pulsar entirely out of our architecture and to instead use a solution combining EMQX for MQTT messaging with Kafka for stream processing. This solution works much better. I had tried to work with Stream Native on the solution for nearly 2 years, in the end we lost faith in not only this project but the entire corporate leadership of the Pulsar project. It's a fantastic software solution on paper, but we've encountered so many issues even beyond even just the scope of MoP that we just could not justify having to constantly fix the solution, and we could not foster a functional relationship with Stream Native enough to trust their ability to support their own software.

[tsturzl]

I had suffered a lot to make MoP run properly(seems properly), and I would recommend you not using it.

I feel this in my soul