2 ms·

> you've essentially circled back around to clients having to use a client with REST-like "synchronous/blocking requests with retry/backpressure" semantics Yes

> you've essentially circled back around to clients having to use a client with REST-like "synchronous/blocking requests with retry/backpressure" semantics Yes, they both do the same thing. That's not even the starting point of the discussion. The implementation from HTTP to a message queue (mailbox system) is the discussion point. Having the caller (who needs work done) wait to be informed when the work is done (or not done) is less deterministic than telling the callee how long before the work doesn't matter anymore. The callee gives back a transaction ID/is provided a callerID or is unavailable, and the caller knows (very quickly) it's not going to get done or knows where to look for the work (or abandon it). Either way, it allows for optimization on both sides.

stolsvik 4y ago
> .. telling the callee how long before the work doesn't matter anymore. That is interesting - this is actually a feature of JMS, which is employed in Mats: You can say that a Mats Flow is nonPersistent (i.e. "not all that important, really"), and in the same call you can also say how many seconds until timeout. <https://mats3.io/javadoc/mats3/0.19/api/io/mats3/MatsInitiator.MatsInitiate.html#nonPersistent(long) https://mats3.io/javadoc/mats3/0.19/api/io/mats3/MatsInitiat...> This is employed by the MatsFuturizer if you use the "nonEssential" invocation: <https://mats3.io/javadoc/mats3/0.19/modern/io/mats3/util/MatsFuturizer.html#futurizeNonessential(java.lang.String,java.lang.String,java.lang.String,java.lang.Class,java.lang.Object) https://mats3.io/javadoc/mats3/0.19/modern/io/mats3/util/Mat...> The point is that if there are too big queues, bunching up even more work on them which will not be processed in time does not make any sense: If the Future on the caller side have already timed out, it makes no sense at all that the callee should process the work and return the answer.

stolsvik 4y ago

> .. telling the callee how long before the work doesn't matter anymore. That is interesting - this is actually a feature of JMS, which is employed in Mats: You can say that a Mats Flow is nonPersistent (i.e. "not all that important, really"), and in the same call you can also say how many seconds until timeout. <https://mats3.io/javadoc/mats3/0.19/api/io/mats3/MatsInitiator.MatsInitiate.html#nonPersistent(long) https://mats3.io/javadoc/mats3/0.19/api/io/mats3/MatsInitiat...> This is employed by the MatsFuturizer if you use the "nonEssential" invocation: <https://mats3.io/javadoc/mats3/0.19/modern/io/mats3/util/MatsFuturizer.html#futurizeNonessential(java.lang.String,java.lang.String,java.lang.String,java.lang.Class,java.lang.Object) https://mats3.io/javadoc/mats3/0.19/modern/io/mats3/util/Mat...> The point is that if there are too big queues, bunching up even more work on them which will not be processed in time does not make any sense: If the Future on the caller side have already timed out, it makes no sense at all that the callee should process the work and return the answer.