stolsvik

14 ms·

91.
by stolsvik 4y ago
Totally agree that HTTP can also be considered message passing, just synchronous! Wrt. returning a Future, this is what the MatsFuturizer does, giving you a sync-async bridge into the "Mats fabric": https://mats3.io&#x2
92.
by stolsvik 4y ago
As the article points out, I feel that messaging really shines when it comes to failures: Instead of an - at best - WARN or ERROR log line amongst millions of log lines, the failing message "pops out" of the messaging fabric, in
93.
by stolsvik 4y ago
You keep saying that, but it is not true.
94.
by stolsvik 4y ago
In a message broker architecture, it is typically the clients connecting to the broker. Thus, as you correctly point out, they need to know where to connect. But that is the same value for every single client. Using the failover transport o
95.
by stolsvik 4y ago
Sorry about that. If you have any questions that could shine light on things, I am happy to answer.
96.
by stolsvik 4y ago
I might not have gotten across clearly wrt. how this works. It is each stage that is transactional. If the stage processing fails (or the node crashes), both the DB transactiona, and the messaging transaction, is rolled back. It is then ret
97.
by stolsvik 4y ago
There is: https://news.ycombinator.com/item?id=34767858
98.
by stolsvik 4y ago
I am not entirely sure. I had bunched dapr together with Istio, as a "service-mesh" layer utilizing side-car pods to mesh the different pieces of your service. Just browsed it again, and there seems to be a bit more tooling in pla
99.
by stolsvik 4y ago
> And hope that the DNS\config propagates to the calling client and that the library can reliably add and remove nodes. This is not how it works. A messaging broker client connects to the message broker. The client then creates receive
100.
by stolsvik 4y ago
I think you're onto it, but not quite? The "distributed CPS" explanation is quite good. There is no "shared mutable state" per se. The "state object" is passed through the stages of the same endpoint , no
101.
by stolsvik 4y ago
The big point with messaging is that you have rollback, and retries. Mats leverages this. If Stage N in the total process has picked up a message, starts to process it, and then something (temporarily) fails (or the node crashes), then it w
102.
by stolsvik 4y ago
This would not work for a exchange. What I work with is an UCITS mutual funds system. Once per day, we get a new price for each fund (the NAV, Net Asset Value). We now need to settle all orders, subscriptions and redemptions , waiting for
103.
by stolsvik 4y ago
Mats does not explicitly define a set "route" through a bunch of stages. I view Camel more like a Workflow system, which is pointed out elsewhere in the discussion threads here - the workflows are defined external to the actual pr
104.
by stolsvik 4y ago
:-) As mentioned a few places, the actor model is actually part of the inspiration behind Mats: https://mats3.io/background/what-is-mats/#attempt-at-a-conde...
105.
by stolsvik 4y ago
Yes, as far as I have come to understand, REST and similar protocols like gRPC are definitely the most common inter-service communications solutions. Witness e.g. Netflix's stack with Hystrix, and the popular Kubernetes add-on Istio se
106.
by stolsvik 4y ago
Mats has two levels of priority: "ordinary" and "interactive". JavaDoc for interactive: < https://mats3.io/javadoc/mats3/0.19/api/io/mats3/MatsInitiat... > Notice that t
107.
by stolsvik 4y ago
> they are using an "async" system to simulate a thread-oriented system with blocking. You can do that, but why? The "simulation" is purely visual, or rather "cognitive load reduction"-wise. It is explained
108.
by stolsvik 4y ago
I believe this is detailed a few places on that website, e.g. here: https://mats3.io/docs/message-oriented-rpc/ “Messaging with a call stack”, “invokable, message-based async endpoints”
109.
by stolsvik 4y ago
:-) I actually mention the actor model as inspiration for Mats here: https://mats3.io/background/what-is-mats/#attempt-at-a-conde...
110.
by stolsvik 4y ago
> If your queue is the bottle neck (yes it happens) how do you know there are more nodes getting added to it? How do you rebalance the topic over multiple new nodes in the queue? In a message queuing system, there is no rebalancing - you
111.
by stolsvik 4y ago
Not sure when you saw the HN post, but the original title was "Why messaging is much better than REST for inter-microservice communications" - @dang / HN changed it. The article specifically points out that this is for inter-
112.
by stolsvik 4y ago
Thanks, I'll take that Erlang-comparison as praise! (I actually mention the actor model as inspiration here: https://mats3.io/background/what-is-mats/#attempt-at-a-conde... )
113.
by stolsvik 4y ago
> message queues are just shared DBs with some extra ordering Completely agree. And I have stated that elsewhere in these threads. I mention it here: https://mats3.io/using-mats/matsfactory/#connecting-to-the-c.
114.
by stolsvik 4y ago
While these ideas was brewing, I ventured down into many libraries, Camel was one of them. It did not solve any of my problems. Mats is messaging with a call stack . One messaging endpoint can invoke another messaging endpoint, and get t
115.
by stolsvik 4y ago
Ops team?! We, the developers, are monitoring the DLQs: It is our mistakes, and we must fix them. Operations' only role is to keep the VMs the ActiveMQ is running on active, and the database it uses responsive. If you used it in a sync
116.
by stolsvik 4y ago
The original title was "Why messaging is much better than REST for inter-microservice communications" - @dang / HN changed it. I feel the change is wrong in at least two ways: The linked article literally argues that messagin
117.
by stolsvik 4y ago
As mentioned here: https://mats3.io/background/system-of-services/ .. Mats is meant to be an inter-service communication solution. It is explicitly not meant to be your front-facing endpoints. If you are DoS&#x2
118.
by stolsvik 4y ago
Hmm. I want to distance this library pretty far from Camel! Wrt. "papering over": Not really. I make it "feel like" you're coding straight down, sequential, linear, as if you're coding synchronously. But if y
119.
by stolsvik 4y ago
Hmm. Maybe not. But they sure have much in common: You define a set of things that should be done, triggered by something - either a schedule, an event (oftentimes a repository event, but it doesn't have to), or from another Github act
120.
by stolsvik 4y ago
Thank you!

More ›