Susan Harkins (241) [Avatar] Offline
#1
Please post errors found in the published version of Reactive Design Patterns here. If necessary, we'll publish a comprehensive list for everyone's convenience. Thank you!

Susan Harkins
Errata Editor
Manning Publications
Phil Derome (33) [Avatar] Offline
#2
There isn't any so far after reading two chapters. The author(s) is/are remarkably skilled at writing. High praise!
Phil Derome (33) [Avatar] Offline
#3
Listing 3.3 suggests claims it's referentially transparent.

I am not convinced that this is strictly referential transparent (and if it is not, I'd agree that it's a nitpick that does not invalidate the point being made). My skepticism is based on the possibility that the code is not thread safe. And the possibility for the code being thread unsafe would be the possibility that copying a double from RHS to a variable is non-atomic (I don't know whether that's the case).

In detail now: considering two competing threads trying to compute getRoot on same object Rooter of a very large number at the same time when the root has never been computed, and now the two threads are about to initialize the root value at the same time concurrently. It's conceivable (it depends on knowledge of JVM double atomicity properties, which I don't know) that second thread produces temporary garbage while setting the root as the copy of the double might not be atomic, and at that unpleasant moment, the first thread returns this garbage value as the evaluated root. This would break referential transparency if the double copy is not atomic.
Phil Derome (33) [Avatar] Offline
#4
Quote (Ch 3), incorrect reference to listing 3.5 (and link): "Every call to
next()
will return a different value. Consequently, the result of something like the example in listing 3.5 can give you a very unpleasant experience: "

There is small code fragment that follows but it does not have a number (such as 3.5) whereas Listing 3.4 just before seems relevant. Definitely Listing 3.5 is much further and is unrelated to the discussion. Perhaps, all that is required is not to quote any listing and simply state "in following code" or something equivalent.

The following statement which includes
SideEffecting(Integer.MAX_VALUE 2)
likely has a missing minus sign in front of 2 as
MAX_VALUE 2
is not a valid arithmetic expression.

The side bar comment for the code (Probably meant to reference the variable!) is unclear. Maybe it's meant simply "... the variable next!" ?
Phil Derome (33) [Avatar] Offline
#5
Chapter 3. This sentence and the listing reference is confusing: Listing 3.6 demonstrates this technique with the .anyOf method of CompletableFuture: it returns whichever Future finishes first.

In fact, that happens in Listing 3.5, not 3.6. The discussion however is close to the Scala (not Java) Listing 3.6. So, it's not entirely clear whether the author wants to refer to the listing closest to the text (3.6 Scala) or simply needed some time to get to talk to one of the two listings, with a preference for Java, which seems more mainsteam for the book (and hence the choice of 3.5).
Roland Kuhn (15) [Avatar] Offline
#6
Phil Derome wrote:Listing 3.3 suggests claims it's referentially transparent.

I am not convinced that this is strictly referential transparent (and if it is not, I'd agree that it's a nitpick that does not invalidate the point being made). My skepticism is based on the possibility that the code is not thread safe. And the possibility for the code being thread unsafe would be the possibility that copying a double from RHS to a variable is non-atomic (I don't know whether that's the case).

In detail now: considering two competing threads trying to compute getRoot on same object Rooter of a very large number at the same time when the root has never been computed, and now the two threads are about to initialize the root value at the same time concurrently. It's conceivable (it depends on knowledge of JVM double atomicity properties, which I don't know) that second thread produces temporary garbage while setting the root as the copy of the double might not be atomic, and at that unpleasant moment, the first thread returns this garbage value as the evaluated root. This would break referential transparency if the double copy is not atomic.


Fortunately, writes of object references (which we are dealing with here) are always atomic, as mandated by §17.7 of the Java Language Specification.
Roland Kuhn (15) [Avatar] Offline
#7
Phil Derome wrote:Quote (Ch 3), incorrect reference to listing 3.5 (and link): "Every call to
next()
will return a different value. Consequently, the result of something like the example in listing 3.5 can give you a very unpleasant experience: "

There is small code fragment that follows but it does not have a number (such as 3.5) whereas Listing 3.4 just before seems relevant. Definitely Listing 3.5 is much further and is unrelated to the discussion. Perhaps, all that is required is not to quote any listing and simply state "in following code" or something equivalent.


True, it should just say “following example”, I’ll add this to the errata.

The following statement which includes
SideEffecting(Integer.MAX_VALUE 2)
likely has a missing minus sign in front of 2 as
MAX_VALUE 2
is not a valid arithmetic expression.


Hmm, both the eBook and the pBook to have the minus sign in there, as far as I can see.

The side bar comment for the code (Probably meant to reference the variable!) is unclear. Maybe it's meant simply "... the variable next!" ?


There is only one variable in the snippet, so I don’t see how it is unclear, could you elaborate?
Roland Kuhn (15) [Avatar] Offline
#8
Phil Derome wrote:Chapter 3. This sentence and the listing reference is confusing: Listing 3.6 demonstrates this technique with the .anyOf method of CompletableFuture: it returns whichever Future finishes first.

In fact, that happens in Listing 3.5, not 3.6. The discussion however is close to the Scala (not Java) Listing 3.6. So, it's not entirely clear whether the author wants to refer to the listing closest to the text (3.6 Scala) or simply needed some time to get to talk to one of the two listings, with a preference for Java, which seems more mainsteam for the book (and hence the choice of 3.5).


Good catch, that sentence is indeed a reference to listing 3.5, pulled into the Scala context for comparison—I agree that that paragraph is a little dense. The correction to the reference can be done via an erratum, expanding the paragraph is unfortunately not possible (unless we are talking about a second edition).
Roland Kuhn (15) [Avatar] Offline
#9
Phil Derome wrote:There isn't any so far after reading two chapters. The author(s) is/are remarkably skilled at writing. High praise!


Thanks for the praise, that is always a pleasure to hear!
Phil Derome (33) [Avatar] Offline
#10
Section 5.5 Message loss, discussion of Figure 5.2 ( I see page 276 in OSX IBooks):

Figure 5.2 clearly delineates role of "Front end" pink box from "Aggregator" light blue box. The discussion however views them as a single unit, not differentiated in my view. Here's the excerpt related to aggregation and browser making me say that:

The front end adds replies from the internal services to this context as they come in, and when the information is complete, it sends the aggregated reply back to the original requester.

This sentence above effectively subsumes "Aggregator" as sub-component of "Front end", which is not how the figure represents message flow.
Phil Derome (33) [Avatar] Offline
#11
Roland Kuhn wrote:
Phil Derome wrote:Quote (Ch 3), incorrect reference to listing 3.5 (and link): "Every call to
next()
will return a different value. Consequently, the result of something like the example in listing 3.5 can give you a very unpleasant experience: "

There is small code fragment that follows but it does not have a number (such as 3.5) whereas Listing 3.4 just before seems relevant. Definitely Listing 3.5 is much further and is unrelated to the discussion. Perhaps, all that is required is not to quote any listing and simply state "in following code" or something equivalent.


True, it should just say “following example”, I’ll add this to the errata.

The following statement which includes
SideEffecting(Integer.MAX_VALUE 2)
likely has a missing minus sign in front of 2 as
MAX_VALUE 2
is not a valid arithmetic expression.


Hmm, both the eBook and the pBook to have the minus sign in there, as far as I can see.

The side bar comment for the code (Probably meant to reference the variable!) is unclear. Maybe it's meant simply "... the variable next!" ?


There is only one variable in the snippet, so I don’t see how it is unclear, could you elaborate?


Phil Derome: Page 175 on OSX IBooks, same problem with Safari Online (I'll get PBook in few days, it crossed Canadian border):
Even worse, something like new SideEffecting(Integer.MAX_VALUE 2) will cause the side effect after a few calls to become an ArithmeticException.
Phil Derome (33) [Avatar] Offline
#12
Roland Kuhn wrote:
Phil Derome wrote:Quote (Ch 3), incorrect reference to listing 3.5 (and link): "Every call to
next()
will return a different value. Consequently, the result of something like the example in listing 3.5 can give you a very unpleasant experience: "

There is small code fragment that follows but it does not have a number (such as 3.5) whereas Listing 3.4 just before seems relevant. Definitely Listing 3.5 is much further and is unrelated to the discussion. Perhaps, all that is required is not to quote any listing and simply state "in following code" or something equivalent.


True, it should just say “following example”, I’ll add this to the errata.

The following statement which includes
SideEffecting(Integer.MAX_VALUE 2)
likely has a missing minus sign in front of 2 as
MAX_VALUE 2
is not a valid arithmetic expression.


Hmm, both the eBook and the pBook to have the minus sign in there, as far as I can see.

Phil Derome: page 175 on OSX IBook lacks it, and similarly for Safari Online (pBook presumably fine, I'll get it in a few days)

The side bar comment for the code (Probably meant to reference the variable!) is unclear. Maybe it's meant simply "... the variable next!" ?


There is only one variable in the snippet, so I don’t see how it is unclear, could you elaborate?
Phil Derome (33) [Avatar] Offline
#13
Roland Kuhn wrote:
Phil Derome wrote:Quote (Ch 3), incorrect reference to listing 3.5 (and link): "Every call to
next()
will return a different value. Consequently, the result of something like the example in listing 3.5 can give you a very unpleasant experience: "

There is small code fragment that follows but it does not have a number (such as 3.5) whereas Listing 3.4 just before seems relevant. Definitely Listing 3.5 is much further and is unrelated to the discussion. Perhaps, all that is required is not to quote any listing and simply state "in following code" or something equivalent.


True, it should just say “following example”, I’ll add this to the errata.

The following statement which includes
SideEffecting(Integer.MAX_VALUE 2)
likely has a missing minus sign in front of 2 as
MAX_VALUE 2
is not a valid arithmetic expression.


Hmm, both the eBook and the pBook to have the minus sign in there, as far as I can see.

The side bar comment for the code (Probably meant to reference the variable!) is unclear. Maybe it's meant simply "... the variable next!" ?


There is only one variable in the snippet, so I don’t see how it is unclear, could you elaborate?
Phil Derome: The arrow points to logger.debug statement, which has no variable (has se.next()). There's ambiguity as to whether the variable is se or next (final int next = se.next(); above)
Phil Derome (33) [Avatar] Offline
#14
Roland Kuhn wrote:
Phil Derome wrote:Listing 3.3 suggests claims it's referentially transparent.

I am not convinced that this is strictly referential transparent (and if it is not, I'd agree that it's a nitpick that does not invalidate the point being made). My skepticism is based on the possibility that the code is not thread safe. And the possibility for the code being thread unsafe would be the possibility that copying a double from RHS to a variable is non-atomic (I don't know whether that's the case).

In detail now: considering two competing threads trying to compute getRoot on same object Rooter of a very large number at the same time when the root has never been computed, and now the two threads are about to initialize the root value at the same time concurrently. It's conceivable (it depends on knowledge of JVM double atomicity properties, which I don't know) that second thread produces temporary garbage while setting the root as the copy of the double might not be atomic, and at that unpleasant moment, the first thread returns this garbage value as the evaluated root. This would break referential transparency if the double copy is not atomic.


Fortunately, writes of object references (which we are dealing with here) are always atomic, as mandated by §17.7 of the Java Language Specification.
Phil Derome: ah yes, I see now: Double root is an object, not a native double Java type.
Phil Derome (33) [Avatar] Offline
#15
Wording, Chapter 6: I prefer "bit by bit" over "bite by bite"

Bite by bite you take apart the big task, ...

Phil Derome (33) [Avatar] Offline
#16
Chapter 7, typo:
No other module will do so in its stead.
Phil Derome (33) [Avatar] Offline
#17
Chapter 10, p. 121 (pBook), Figure 10.1, box should state "Per-user storage" in place of "Per-use storage" to match corresponding text.
Phil Derome (33) [Avatar] Offline
#18
more observation on clarity than typo, Figure 10.2 and Section 10.3, page 123 (pBook).

Discussion seems to emphasize horizontal message flow, which is represented in diagram by the main horizontal series of 4 boxes. The problem is that the rightmost 2 boxes have no caption (indeed not needed in the text) and it leads a bit of a questioning from the reader as to what it represents. The storage drum at the bottom is so conventional in industry that it does not even warrant attention even though it has no caption either.

Maybe some ellipsis symbols would do or some "cloudy" diagram to represent the continuation of the horizontal stream. I don't have a strong recommendation as to what would look best.
Phil Derome (33) [Avatar] Offline
#19
Section 10.6 page 124 (pBook), incorrect plural in first bullet: "A modules does one job..."
Phil Derome (33) [Avatar] Offline
#20
Section 10.6 Summary: the summary is effectively a summary of the whole of Part 2 of the book as opposed to be a small summary of Chapter 10. Either we separate more cleanly a summary of chapter 10 proper and state we are also summarizing Part 2 or potentially we don't summarize Part 2 at all.

Section 3.4.7 at end of Part 1 is also unconventional summary in that sense. First it should be labelled 3.5. Most of its text is actually about motivating Part 2. Why not integrate that discussion with Part 2 intro itself at pages 65-66 instead?

As a matter of opinion, I find that chapter summaries would suffice and discussion of a whole of one of the major parts of the book could be limited at the introduction of the parts.
Phil Derome (33) [Avatar] Offline
#21
Section 11.3.4 Providing synchronous execution engines has discussion on CallingThreadDispatcher and says "see the source code archives for details". I cannot find the details on github for CallingThreadDispatcher, so it looks like an oversight.
Phil Derome (33) [Avatar] Offline
#22
Listing 11.26 Removing supervision from the test

failureParent is defined twice, the first one incorrectly with a typo (no parameter and no closing parenthesis) and 2 lines below correctly using props as parameter. The accompanying github code looks to be correct and defines it only once.
Phil Derome (33) [Avatar] Offline
#23
Chapter 13, Replication patterns, page 189 (pBook), 2nd large paragraph:

as can be seen in the definition of the running behaviour in listing 13.1.

It should be 13.2.
Roland Kuhn (15) [Avatar] Offline
#24
Thanks a lot, Phil! I have compiled a list of errata (to be published on manning.com soon, too).
Phil Derome (33) [Avatar] Offline
#25
pbook, 14.1.2, p226, grammar usage makes a sentence hard to understand, specifically "about ..." as I cannot see "about what it is", the remaining aspect that we need to discuss in the context of the Resource Encapsulation pattern is how to model knowledge about and management of the worker nodes within the execution component

Maybe the word "and" that follows "about" does not belong in "about and management".
Roland Kuhn (15) [Avatar] Offline
#26
Phil Derome wrote:pbook, 14.1.2, p226, grammar usage makes a sentence hard to understand, specifically "about ..." as I cannot see "about what it is", the remaining aspect that we need to discuss in the context of the Resource Encapsulation pattern is how to model knowledge about and management of the worker nodes within the execution component

Maybe the word "and" that follows "about" does not belong in "about and management".


It means «to model (knowledge about) and (management of) the worker nodes». At present I do not have a brilliant idea on how to improve this wording without introducing much repetition.
385511 (2) [Avatar] Offline
#27
"The cost rises dramatically in a distributed system, mostly because confirmations require network round trips having latencies orders of magnitude larger than on a local system".

I don't quite understand what "latencies" means. I think it might be "latency"?

It's in section 4.6, page 77.
385511 (2) [Avatar] Offline
#28
In Figure 10.1, I see "per-use storage", but according to the context, it should be "per-user storage".