Confirmed, the synchronization sequence limits publish service to publish one event in a time, i.e. an event is published only when publishing of a previous one has been finished.

I tried to compare current implementation of publish service with one without the synchronized section and I didn't observe any performance difference. Publishing took roughly the same time: non-synchronized version 1% faster.

I tested in Docker environment and I suspect that MB was a bottleneck. I'll continue testing.

@magnusbaeck, can you perform testing if I provide you non-synchronized version?

I did testing using real machines (not Docker containers) and I found that publishing without synchronized section is cca 15-20% faster (publishing up to cca 100 events).

Sorry, I was away last week and have had to spend some time this week on getting back on track. Yes, I can do some load testing.

100 events/s sounds very low. How many concurrent client connections did you run?

No, it's a misunderstanding. Version without synchronization is 15-20% faster when publishing up to 100 events. Then the spped advantage drops down gradually and when publishing cca 10000 events, performance of both, synchronized and non-synchronized versions, becomes the same.

Overall performance I achieved on my setup was cca 3000events/sec.

As you stated in your comment (#219 (comment)), the problem arises from inside of MessageServiceRMQImpl. The implementation has never been prepared to work in parallel/concurrent environment.

Originally, I had an impression that the implementation is located in semantics library. But, fortunately, it isn't. So that could be altered as part of publish service.