Today I tried spring reactor with the following example: messaging-reactor
It is basically requesting a random quote from a given URL and printing it out to a console. It is a nice example to show how the publishing and consuming works with spring reactor and without blocking anything.
But I have a small problem. In the example there is one receiver (consumer) defined and the output with one is the following:
Quote 4: Really loving Spring Boot, makes stand alone Spring apps easy.
Quote 6: So easy it is to switch container in #springboot.
Quote 7: Working with Spring Boot is like pair-programming with the Spring developers.
Quote 8: Really loving Spring Boot, makes stand alone Spring apps easy.
Quote 5: I have two hours today to build an app from scratch. @springboot to the rescue!
Quote 2: The real benefit of Boot, however, is that it's just Spring. That means any direction the code takes, regardless of complexity, I know it's a safe bet.
Quote 1: With Boot you deploy everywhere you can find a JVM basically.
Quote 3: With Boot you deploy everywhere you can find a JVM basically.
Quote 6: I don't worry about my code scaling. Boot allows the developer to peel back the layers and customize when it's appropriate while keeping the conventions that just work.
Quote 8: I have two hours today to build an app from scratch. @springboot to the rescue!
Elapsed time: 841ms
Average time per quote: 84ms
I added a second receiver (consumer):
@Autowired
private Receiver receiver;
@Autowired
private Receiver receiver2;
@Override
public void run(String... args) throws Exception {
this.eventBus.on($("quotes"), this.receiver);
this.eventBus.on($("quotes"), this.receiver2);
this.publisher.publishQuotes(NUMBER_OF_QUOTES);
}
So now I got two receivers and the output is:
Quote 4: Really loving Spring Boot, makes stand alone Spring apps easy.
Quote 6: So easy it is to switch container in #springboot.
Quote 7: Working with Spring Boot is like pair-programming with the Spring developers.
Quote 8: Really loving Spring Boot, makes stand alone Spring apps easy.
Quote 5: I have two hours today to build an app from scratch. @springboot to the rescue!
Quote 2: The real benefit of Boot, however, is that it's just Spring. That means any direction the code takes, regardless of complexity, I know it's a safe bet.
Quote 1: With Boot you deploy everywhere you can find a JVM basically.
Quote 3: With Boot you deploy everywhere you can find a JVM basically.
Quote 6: I don't worry about my code scaling. Boot allows the developer to peel back the layers and customize when it's appropriate while keeping the conventions that just work.
Quote 8: I have two hours today to build an app from scratch. @springboot to the rescue!
Elapsed time: 841ms
Average time per quote: 84ms
2017-06-25 19:15:25.137 INFO 2700 --- [ main] d.hof.fronetic.demo.reactor.Application : Started Application in 4.103 seconds (JVM running for 4.374)
Quote 7: It embraces convention over configuration, providing an experience on par with frameworks that excel at early stage development, such as Ruby on Rails.
Quote 2: I have two hours today to build an app from scratch. @springboot to the rescue!
Quote 5: Spring has come quite a ways in addressing developer enjoyment and ease of use since the last time I built an application using it.
Quote 3: So easy it is to switch container in #springboot.
Quote 1: I have two hours today to build an app from scratch. @springboot to the rescue!
Quote 10: With Boot you deploy everywhere you can find a JVM basically.
Quote 9: Previous to Spring Boot, I remember XML hell, confusing set up, and many hours of frustration.
Quote 4: Spring Boot solves this problem. It gets rid of XML and wires up common components for me, so I don't have to spend hours scratching my head just to figure out how it's all pieced together.
Quote 9: It embraces convention over configuration, providing an experience on par with frameworks that excel at early stage development, such as Ruby on Rails.
Quote 10: Spring Boot solves this problem. It gets rid of XML and wires up common components for me, so I don't have to spend hours scratching my head just to figure out how it's all pieced together.
So as you can see, instead of 10 Quotes I now got 20 quotes. But that is not how consumers should work in my opinion. pls tell me if im wrong but I thought if a consumer is receiving a notification it is consuming this notification so that no other receiver can receive this notification. In the above example each consumer is performing the same work. What if I want to share all the work (printing 10 quotes) between those two consumers so that in an optimal scenario each consume would consume 5 notifications. Isnt this one of the main tasks for those publisher / consumer reactors?
I think you're confusing point to point messaging with publish and subscribe. Your intuitive model is what happens with point to point messaging, where a consumer takes a message off a queue so that no other process may consume it. Event based models are different however because the require a process publish a message to a forum that informs 'all' listeners simultaneously.
You have the latter -- an event based system. Your listeners are subscribed to the same channel and respond to the same messages at the same time.