Блокирането е лошо, тъй като свързва нишка, чакаща отговор. Това е много лошо в реактивна рамка, която има малко нишки на свое разположение и е проектирана така, че нито една от тях трябва да бъдат ненужно блокирани.
Това е точното нещо, което реактивните рамки са проектирани да избягват, така че в този случай просто ви спира да го правите:
Вашият нов код, за разлика от това, работи асинхронно. Нишката не е блокирана, тъй като всъщност нищо не се случва, докато хранилището не върне стойност (и след това ламбда, която сте предали на savedQuote.subscribe() се изпълнява, отпечатвайки вашия резултат на конзолата.)
Новият код обаче все още не е оптимален/нормален от гледна точка на реактивни потоци, тъй като правите цялата си логика в метода си за абониране. Нормалното нещо, което трябва да направите, е да ни изпратите серия от извиквания на flatMap/map, за да преобразуваме елементите в потока и да използваме doOnNext() за странични ефекти (като отпечатване на стойност):
stockQuoteClient.getQuoteStream()
.log("quote-monitor-service")
.flatMap(quoteRepository::insert)
.doOnNext(result -> System.out.println("I saved a quote! Id :: " + result.getId())))
.subscribe();
Ако вършите някаква сериозна работа с реакторни/реактивни потоци, би си струвало да прочетете за тях като цяло. Те са много мощни за работа без блокиране, но изискват различен начин на мислене (и кодиране) от по-„стандартната“ Java.
