The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

kubert (2) [Avatar] Offline
#1
Chapter 1.6 could be understood and implemented naively: Create a new thread per request and let it handle the request. This could lead to serious efficiency problems in the large. So I'd like to see a clarification, that the implementation needs e.g. to use a thread pool which processed all the requests actively.

In my opinion an implementation of the given problem should also prefer asynchronous calls to leave room for further optimizations. Put the request in some kind of queue, let a thread pool process that actively, and let the client periodically check for the answer (or cancel the request). This makes sense if third party systems are involved, because one cannot forsee how long it will take to get the third party response anyway. (see 3.1.2 Decoupled Invocation)

You should also discuss typical failure scenarious. E.g. if the third party service would not react at all for 1h, there could be a massive amount of threads created that cannot calculate the desired response. If you solve it using message queues, they can fill up easily. So there should be some kind of time-out handling: If the response could not be calculated in a given time or at it's own disposal (e.g. if queues fill up), the service should be free to reply with a "try-again-later" response (and thereby get rid of the currently unfulfillable request).

BTW, if you are writing a book about pattern I would consider it good style to have something like a pros/cons/alternatives/discussion section for each pattern (see Gamma/GOF).
arnonrgo (62) [Avatar] Offline
#2
Re: 1.6 Active Service Pattern: Beware of naive implementation
Hi Michael
I am not sure what you are referring to here . Chapter 1 only has 4 sections (1.4) and The Active Service pattern (2.2) talks about having at least one thread that handles on-going concerns (i.e. not requests) and not about creating a thread per incoming request (which I agree is not a good option)

If you are indeed talking about the Active Service pattern in chapter 2 - can you please show me a quote where it can be understood the way you mentioned it

Regarding Pros/Cons etc. I do discuss it as part of the discussion of each pattern - unlike the GoF book, however, I opted for a pattern description style which is closer to the Alexandrian form and instead of a lot of headings I (try to) weave things into the text

Thanks for your comment

Arnon

PS
Sorry for the delay in answering - I was out of office last week

Arnon
kubert (2) [Avatar] Offline
#3
Re: 1.6 Active Service Pattern: Beware of naive implementation
Hi Arnon,

yes, I'm talking about the Active Service pattern. The Early Access PDF has a broken numbering scheme (Chapter 2 has 1.5-1.11), which I used.

Regarding the threads: You probably understand it that way, because for you it's obvious. Unfortunately I met lots of (maybe less skilled) people who will read "at least one thread" as "one thread per request is ok". So I'd propose that you just add a clarifying sentence just to help avoiding some bad implementations.

It's not that unlikely that somebody naively would implement one thread per request, because several simple HTTP servers e.g. in Java were built like this, especially in educational literature.

Pros/Cons etc.: The disadvantage of less formal structure is that it makes it hard to use the book as a reference. Maybe you could add some "formal" references at the end of each pattern with references to related patterns?

Michael
arnonrgo (62) [Avatar] Offline
#4
Re: 1.6 Active Service Pattern: Beware of naive implementation
> yes, I'm talking about the Active Service pattern.
> The Early Access PDF has a broken numbering scheme
> (Chapter 2 has 1.5-1.11), which I used.

Oh, ok, I hope they'll fix that

". So I'd propose that you just add a clarifying
> sentence just to help avoiding some bad
> implementations.

Thanks for the suggestion, I'll do that. "one thread per request" was definitely not my intention


>
> Pros/Cons etc.: The disadvantage of less formal
> structure is that it makes it hard to use the book as
> a reference. Maybe you could add some "formal"
> references at the end of each pattern with references
> to related patterns?

There will be a pattern map in chapter 1 - but I'll also bring up your suggestion to my editor

Thanks for the feedback

Arnon