Stateless actors are not concurrent.

[juanstiza]

The documentation states:

Stateless actors can service multiple requests at the same time. Statelessness means that such actors do not have to cater for concurrency issues.

I assumed (and please correct me if I am wrong) that we could call these actors with any concurrency we desire.

Expected Behavior

Multiple messages being sent to a stateless actor should be processed in parallel

Current Behavior

Messages are being processed one at a time

Possible Solution

No clue

Steps to Reproduce (for bugs)

import nact from "nact";
const system = nact.start();
const delay = (time) => new Promise((res) => setTimeout(res, time));

const ping = nact.spawnStateless(
  system,
  async (msg, ctx) => {
    console.log(msg);
    console.log(new Date())
    await delay(500);

    throw new Error("oh no!");
  },
  "ping",
  {
    onCrash: (msg, e, ctx) => {
      console.log(e)
      return ctx.escalate
    }
  }
);

for (let i = 0; i < 5; i++) {
  nact.dispatch(ping, {
    i,
    createdAt: new Date()
  });
}

This outputs:

{ i: 0, createdAt: 2023-07-06T13:43:31.932Z }
2023-07-06T13:43:31.937Z
{ i: 1, createdAt: 2023-07-06T13:43:31.932Z }
2023-07-06T13:43:32.440Z
{ i: 2, createdAt: 2023-07-06T13:43:31.932Z }
2023-07-06T13:43:32.942Z
{ i: 3, createdAt: 2023-07-06T13:43:31.932Z }
2023-07-06T13:43:33.444Z
{ i: 4, createdAt: 2023-07-06T13:43:31.932Z }
2023-07-06T13:43:33.947Z

Context

I'm trying to run simple tasks in stateless actors and be able to run them with any desired cocurrency

Your Environment

Tested in node v14.21.3 and v18.14.2 on MacOS 13.4.1

[ncthbrt]

Thanks for reporting this @juanstiza.

[larsw]

Node.js is single-threaded, so it isn't possible to achieve true concurrency.

[juanstiza]

@larsw That is true, but it is not what this ticket is referencing to. Have you read it?

[le0-0]

Right now, parameters from spawnStateless [actor] are just relayed to a spawn [αctor] call. In other words, stateless actors are implemented as normal stateful actors that just ignore their own state, which is why they wait for previous messages handling to complete.

I assume the reason one would want to use stateless actors instead of just calling functions (async or otherwise) is for the supervision and to otherwise reduce the conceptual model of the application by using as few concepts as possible.

A suggestion for another way we could implement spawnStateless is to create an actor that spawns a new child actor to handle each new message the "stateless" actor receives. This approach would (1) not go against restrictions in the actor model, (2) appear to be stateless from the consumers perspective, (3) maintain supervision, and (4) be more eager to process messages when they arrive. It is, however, an approach that could have significant overhead.

Reaching a point where the overhead performance can be tested is probably quite easy, so a fine strategy is probably just to try and implement it and see how it goes.

I guess another discussion that could take place is whether spawnStateless even belongs in @nact/core or if it is a specialized actor type that belongs in a library specializing in implementing reusable actor variants. Other actor variants could be spawnPublisher (that multicasts messages to multiple consumers) and spawnDistinctFilter (that relays messages to a consumer if it is distinct from the previous or all previous messages). Among the operators of RxJS (a library that implements observables in JS/TS, which I would say is conceptually related to the actor model), my two examples are marked with red, while what the spawnStateless in reality does is analogous to what mergeMap (marked in blue) does – showing that they are on a similar level of abstraction.