You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I came across a use case where application sends multiple "business-objects" in one JMS message and also gets batched response back. That is, a response can contain multiple business objects, but there is no guarantee that all business objects from request will be inside one response. Actually it's rather unlikely to happen.
Each business object has unique id that is also send back in response.
I tried to use Gatling for performance testing of this application, but it looks like the assumption is that one JMS message can only contain one id.
I hacked around and modified the code and made it work, but this is breaking change as the JmsMessageMatcher interface changed as it's returning Seq[String] now instead of single String.
Can someone have a look and perhaps suggest how to add support for such feature in a backward compatible manner?
I was thinking perhaps to create new "batched" interface of matcher and provide some implicit conversion from the current Interface to the new "batched" interface. Any better ideas?
One thing I noticed now is that even though the solution works, that is, the tests complete, they report not the total number of the "business objects" but rather a total number of JMS messages.
That is. if there was X JMS messages with Y business objects inside, I would like to see the X * Y count reported and the times should be measured from the time a "business object" is sent to the time when there's response for that same "business object" coming back.
I don't think your suggested solution works. It think what you would need would be a way to preprocess the JMS messages so you can split them before they get handed over to the checks.
I don't think your suggested solution works. It think what you would need would be a way to preprocess the JMS messages so you can split them before they get handed over to the checks.
I guess it "works" for me because I don't do any checks. Just fire all those messages, wait for their return and measure the time.
If you can guide me which parts of the code where would be a good place to do the splitting then I will have a look
Hi.
I came across a use case where application sends multiple "business-objects" in one JMS message and also gets batched response back. That is, a response can contain multiple business objects, but there is no guarantee that all business objects from request will be inside one response. Actually it's rather unlikely to happen.
Each business object has unique id that is also send back in response.
I tried to use Gatling for performance testing of this application, but it looks like the assumption is that one JMS message can only contain one id.
I hacked around and modified the code and made it work, but this is breaking change as the
JmsMessageMatcher
interface changed as it's returningSeq[String]
now instead of singleString
.Can someone have a look and perhaps suggest how to add support for such feature in a backward compatible manner?
I was thinking perhaps to create new "batched" interface of matcher and provide some implicit conversion from the current Interface to the new "batched" interface. Any better ideas?
PR with the hacky solution: #4539
The text was updated successfully, but these errors were encountered: