diff --git a/docs/articles/actors/di-core.md b/docs/articles/actors/di-core.md
index 2ffc398a96a..a9d72c4de07 100644
--- a/docs/articles/actors/di-core.md
+++ b/docs/articles/actors/di-core.md
@@ -11,7 +11,7 @@ title: DI Core
**Akka.DI.Core** is an **ActorSystem extension** library for the Akka.NET
framework that provides a simple way to create an Actor Dependency Resolver
-that can be used an alternative to the basic capabilities of [Props](Props)
+that can be used an alternative to the basic capabilities of [Props](xref:receive-actor-api#props)
when you have actors with multiple dependencies.
# How do you create an Extension?
diff --git a/docs/articles/actors/fault-tolerance.md b/docs/articles/actors/fault-tolerance.md
index 4bb49ce5106..20cd32e966e 100644
--- a/docs/articles/actors/fault-tolerance.md
+++ b/docs/articles/actors/fault-tolerance.md
@@ -115,7 +115,7 @@ by overriding the `logFailure` method.
## Supervision of Top-Level Actors
Top-level actors means those which are created using `system.ActorOf()`, and
-they are children of the [User Guardian](User guardian). There are no
+they are children of the [User Guardian](xref:supervision#user-the-guardian-actor). There are no
special rules applied in this case, the guardian simply applies the configured
strategy.
diff --git a/docs/articles/concepts/actors.md b/docs/articles/concepts/actors.md
index bbe9fa30a77..5b3bd093c98 100644
--- a/docs/articles/concepts/actors.md
+++ b/docs/articles/concepts/actors.md
@@ -7,7 +7,7 @@ title: Actors
The previous section about [Actor Systems](xref:actor-systems) explained how actors form hierarchies and are the smallest unit when building an application. This section looks at one such actor in isolation, explaining the concepts you encounter while implementing it. For a more in depth reference with all the details please refer to F# API or C# API.
-An actor is a container for [State](#state), [Behavior](#behavior), a [Mailbox](#mailbox), [Children](#children) and a [Supervisor Strategy](#supervisor-strategy). All of this is encapsulated behind an [Actor Reference](#actor-reference). One noteworthy aspect is that actors have an explicit lifecycle, they are not automatically destroyed when no longer referenced; after having created one, it is your responsibility to make sure that it will eventually be terminated as well—which also gives you control over how resources are released [When an Actor Terminates](#when-an-actor-terminates).
+An actor is a container for [State](#state), [Behavior](#behavior), a [Mailbox](#mailbox), [Children](#child-actors) and a [Supervisor Strategy](#supervisor-strategy). All of this is encapsulated behind an [Actor Reference](#actor-reference). One noteworthy aspect is that actors have an explicit lifecycle, they are not automatically destroyed when no longer referenced; after having created one, it is your responsibility to make sure that it will eventually be terminated as well—which also gives you control over how resources are released [When an Actor Terminates](#when-an-actor-terminates).
diff --git a/docs/articles/intro/what-problems-does-actor-model-solve.md b/docs/articles/intro/what-problems-does-actor-model-solve.md
index 8ffa2c35052..55f5a9d34f4 100644
--- a/docs/articles/intro/what-problems-does-actor-model-solve.md
+++ b/docs/articles/intro/what-problems-does-actor-model-solve.md
@@ -1,5 +1,5 @@
---
-uid: what-are-actors
+uid: what-problems-does-actor-model-solve
title: What problems does the actor model solve?
---
# What problems does the actor model solve?
@@ -186,7 +186,7 @@ In this way, actors actually achieve the execution we imagined for objects:
An important difference of passing messages instead of calling methods is that messages have no return value.
-By sending a message, an actor delegates work to another actor. As we saw in [The illusion of a call stack](what-are-actors.md#the-illusion-of-a-call-stack),
+By sending a message, an actor delegates work to another actor. As we saw in [The illusion of a call stack](what-problems-does-actor-model-solve.md#the-illusion-of-a-call-stack),
if it expected a return value, the sending actor would either need to block or to execute the other actor's work on the same thread.
Instead, the receiving actor delivers the results in a reply message.
diff --git a/docs/articles/persistence/event-sourcing.md b/docs/articles/persistence/event-sourcing.md
index d06492fcd39..055087e4853 100644
--- a/docs/articles/persistence/event-sourcing.md
+++ b/docs/articles/persistence/event-sourcing.md
@@ -219,7 +219,7 @@ protected override void PreStart()
If persistence of an event is rejected before it is stored, e.g. due to serialization error, `OnPersistRejected` will be invoked (logging a warning by default), and the actor continues with next message.
-If there is a problem with recovering the state of the actor from the journal when the actor is started, `OnRecoveryFailure` is called (logging the error by default), and the actor will be stopped. Note that failure to load snapshot is also treated like this, but you can disable loading of snapshots if you for example know that serialization format has changed in an incompatible way, see [Recovery customization](#recovery customization).
+If there is a problem with recovering the state of the actor from the journal when the actor is started, `OnRecoveryFailure` is called (logging the error by default), and the actor will be stopped. Note that failure to load snapshot is also treated like this, but you can disable loading of snapshots if you for example know that serialization format has changed in an incompatible way, see [Recovery customization](#recovery-customization).
## Atomic writes
Each event is of course stored atomically, but it is also possible to store several events atomically by using the `PersistAll` or `PersistAllAsync` method. That means that all events passed to that method are stored or none of them are stored if there is an error.
diff --git a/docs/articles/streams/pipeliningandparallelism.md b/docs/articles/streams/pipeliningandparallelism.md
index 6d16d4d4407..111a276c474 100644
--- a/docs/articles/streams/pipeliningandparallelism.md
+++ b/docs/articles/streams/pipeliningandparallelism.md
@@ -52,7 +52,7 @@ parallelisable (for example because the result of a processing step depends on a
step). One drawback is that if the processing times of the stages are very different then some of the stages will not
be able to operate at full throughput because they will wait on a previous or subsequent stage most of the time. In the
pancake example frying the second half of the pancake is usually faster than frying the first half, ``fryingPan2`` will
-not be able to operate at full capacity [*1](_).
+not be able to operate at full capacity [1].
> [!NOTE]
> Asynchronous stream processing stages have internal buffers to make communication between them more efficient.
@@ -171,5 +171,5 @@ compared to the parallel pipelines. This pattern rebalances after each step, whi
at the entry point of the pipeline. This only matters however if the processing time distribution has a large
deviation.
-[*1](_) Bartosz's reason for this seemingly suboptimal procedure is that he prefers the temperature of the second pan
+[1] Bartosz's reason for this seemingly suboptimal procedure is that he prefers the temperature of the second pan
to be slightly lower than the first in order to achieve a more homogeneous result.
diff --git a/docs/articles/toc.yml b/docs/articles/toc.yml
index ea88912f25a..d9040a116c2 100644
--- a/docs/articles/toc.yml
+++ b/docs/articles/toc.yml
@@ -2,8 +2,8 @@
items:
- name: What is Akka.NET?
href: intro/what-is-akka.md
- - name: What are actors?
- href: intro/what-are-actors.md
+ - name: What problems does the actor model solve?
+ href: intro/what-problems-does-actor-model-solve.md
- name: Akka.NET Libraries and Modules
href: intro/modules.md
- name: Part 1. Top-level Architecture
@@ -121,7 +121,7 @@
- name: Streams Cookbook
href: streams/cookbook.md
- name: Configuration
- href: streams/configuration.md
+ href: configuration/akka.streams.md
- name: Networking
items:
- name: I/O
diff --git a/docs/index.md b/docs/index.md
index 9c80d4bbf6f..8d241c82628 100644
--- a/docs/index.md
+++ b/docs/index.md
@@ -98,7 +98,7 @@ h2:before{
The Actor Model provides a higher level of abstraction for writing concurrent and distributed systems. It alleviates the developer from having to deal with explicit locking and thread management, making it easier to write correct concurrent and parallel systems.
Actors were defined in the 1973 paper by Carl Hewitt but have been popularized by the Erlang language, and used for example at Ericsson with great success to build highly concurrent and reliable telecom systems.
- Read more
+ Read more