status of a service,

,
21

Of course, but all things equal, it would be interesting to know how much a 1-thread concurrent trigger outperforms a serial trigger, if at all.

If the claim is that customers in a single-node environment should change serial triggers to 1-thread concurrent triggers for performance reasons, we need to be able to articulate what gain to be expected.

In my humble and personal opinion though, this is a dangerous proposition regardless of how significant the performance gain may be. If a solution requires documents to be subscribed in order, a concurrent trigger should never be used because the fact that the solution is being deployed to a single node today does not preclude it from being deployed to a multi-node cluster tomorrow. This is especially true in today’s elastic computing world.

Percio

22

Hi,

from this point of view agreed.

About the performance gain you should try to get in contact with the author of the wiki article.
Eventually he can provide more details to this.

No one is being forced to change his triggers. You can still choose serial triggers if you want to.

But if it comes to the issue (I just had one of this kind) where concurrent(n threads) is causing problems and you have the choice to go to concurrent(1 thread) or serial, it is easier to just reduce the thread number then to change the mode completely and have to recreate the client on your messaging backbone. Of course this is only possible unless clustering gets involved.

Regards,
Holger