Hi,
Wondering what was the reason behind taking the protocol definition out of the scenario chains definition to the setup/injection point? Finding this somewhat counterintuitive for more involved scenarios. Recently stumbled upon that again when wanted to test two jms requests to different queue systems in one scenario. Splitting into two is always a workaround, but still interesting to know whether the current structure is accidental or intentional.
Thank you,
Mykola.
Hi,
Generally speaking, protocol definition is split from scenario so you can:
reuse a given scenario with different protocol definitions
reuse a given protocol definition with different scenarios
Regarding how queue configuration being embedded in JMS protocol definitions, it wouldn’t make sense to move it in the scenario instead as it’s a shared resources, on contrary to WebSockets where each virtual user has its own.
It currently only support configuring one as it was the logic in place when the JSM support was contributed and it seemed to suffice so far.
Cheers,