ZeroMQ was absolutely solid and stable; incredibly trouble free and the only issues we ran into were when IT teams didn't open the ports we documented in the configuration procedure. (The resultant architecture actually looks a lot like Flink)
In any case, ZeroMQ is a fantastic piece of technology that I feel like I don't see out in the wild quite enough. It's dead simple and incredibly stable from my experience.
You just gave me openstack+zeromq flashbacks
What do mature network applications do instead?
For us, delivering an on-prem commercial off the shelf solution, it was untenable to expect the customer IT team to operate a separate, relatively huge piece of tech (remember, this is 2014). Maybe the heuristics would be different today with K8s and advancement of Kafka. But ZeroMQ as an in-process, distributed messaging layer is dead simple. If your use case requires anything else on top of that, it's on the team to design the right solution like resiliency, statefulness, etc.
For a high throughput, distributed compute focused use case, I think ZMQ is still a great choice for coordinating execution. But Kafka and other options on the market now are great choices for higher order abstractions.
I remember we had a similar use-case. This was for collecting live statistics from a sizable Varnish Cache cluster. We wrote a in memory database to store the data. It's been chugging away for about 10 years now and last I heard the zmq traffic alone was about 3Gbps with zero issues.
We even went as far as writing a Golang version of the VCS server to better handle some of the scaling challenges. I don’t remember the exact library that we are using to call into ZeroMQ, but the CGO overhead was minimal.
IIRC it does all I/O on separate background threads which means every operation actually goes through an inter-thread queue. Which can be good and bad.
http://wiki.zeromq.org/blog:multithreading-magic
There's nothing wrong with the opinions presented there -- but it really wants to own your whole threading / serving stack, and isn't really compatible with e.g. a Rust async tokio binary where threads can "move around" etc.
However, it's not that hard to work around their non-thread-safe nature with a single dispatch thread (e.g., see <https://github.com/nyfix/OZ/blob/master/src/transport.c#L457>), and that approach has other potential benefits.
In any case, newer socket types (e.g., ZMQ_CLIENT) have since been defined that are thread-safe, but necessarily don't support multi-part messages. (They tend to be different in other ways as well -- e.g., ZMQ_RADIO/ZMQ_DISH are "sort of" replacements for the original ZMQ_PUB/ZMQ_SUB sockets, but have other constraints as well).
But the truth is that ZeroMQ has a steep learning curve, and some rather sharp edges that can leave nasty cuts if one is not careful.
If you're interested in becoming familiar with ZeroMQ, you might want to check out our implementation: <https://github.com/nyfix/OZ/>.
Disclaimer: I don't work with any of that tech right now, but I'm looking forward to working with Elixir, which is in the same ecosystem.
I feel like I've heard of many larger companies doing relicenses on their open source without this kind of effort.
Linux doesn’t have a CLA, and it’s the most popular operating system in the world.
A CTA (transfer vs license) does allow unilateral license changes after the fact.
[0] https://heathermeeker.com/2021/06/01/fsf-drops-assignment-re...
There is more background here: https://github.com/zeromq/libzmq/issues/2376
Sometimes companies who do "FOSS" make you sign some sort of agreement that they own the code you produce and you won't have any say about re-licensing, so maybe the projects you're thinking about have done that?
You can do license changes without that however as long as:
1. You license per file in the repository. This can be quite arduous but many projects will move the old licensed stuff into a sub project to make that easier to grok.
2. Your new license is compatible with the old license.
-CEO, iMatix Corporation sprl -23 April 2016
By October 2016 he was dead.
This PR basically merges his final commit.
I find it very sad.
I say all that to mean that anyone being sad about his death is something that Pieter would not have wanted.
Confessions of a Necromancer is his work biography, I was totally caught off-guard how relatable his stories turned out to be.
After reading this I wanted to read everything by him - which I am still in the process of.
MPL works on the “source file” level. You have to release any changes you make to MPL licensed files, but you can link those files into a closed source program any way you like.
Incorrect.
https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynami...
If you statically link against an LGPLed library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application.This is false. You can static link as long as you follow https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynami...
Additionally, LGPL3 can be tweaked to add an exception to allow unrestricted static linking. This is like... exactly what ZeroMQ did.
When you do your own license though lawyers need to figure everything out for just your project.
https://github.com/zeromq/libzmq/issues/4315 and https://github.com/zeromq/libzmq/issues/4455
I wonder what made the maintainer change his mind.
Was that sentence finished?
It's a task that you have to do, since the basic guarantees of 0MQ are almost never enough and is very well explained in the guide. But you have to read it carefully.
It's indeed an intuitive library, but it's far, far from perfect, thus why it has been rewritten countless times by Sustrik (crossroads), then by D'Amore (nanomsg).
The state machine in 0MQ is a nightmare of maintenance and a constant source of tricky bugs. The overall "all sockets in one" design makes things such as reconnection and peer identification pretty much impossible.
Don't get me wrong, there's a lot of good in 0MQ. But calling it a jewel that will be in use for decades is far from reality.