-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
support for multiple business objects inside one jms message #4539
Open
artur-jablonski
wants to merge
43
commits into
gatling:main
Choose a base branch
from
artur-jablonski:multiple-ids-in-one-jms-message
base: main
Could not load branches
Branch not found: {{ refName }}
Could not load tags
Nothing to show
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
support for multiple business objects inside one jms message #4539
artur-jablonski
wants to merge
43
commits into
gatling:main
from
artur-jablonski:multiple-ids-in-one-jms-message
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Motivation: Sad, but latest Apache 2 Akka suffers from (IMO non-sensical) vulnerability that we don't want to get reported in our own libraries.
Motivation: We've been issuing a WARN log for many versions. Time to pull the trigger.
Motivation: Users can be interested in messages received in the background instead of having to perform a check in a blocking way. Modifications: * add `HttpProtocol#wsUnmatchedInboundMessageBufferSize` to define the size of the buffer to store unmatched messages, defaulting to 0. * add `Ws#processUnmatchedMessages` to pass a function and process buffered messages. Messages are sorted by timestamp asc. This operation resets the buffer so the same messages are not provided multiple times. * clear the buffer when sending a message (we expect interest to change then)
Motivation: Users can be interested in messages received in the background instead of having to perform a check in a blocking way. Modifications: * add `HttpProtocol#sseUnmatchedInboundMessageBufferSize` to define the size of the buffer to store unmatched messages, defaulting to 0. * add `Sse#processUnmatchedMessages` to pass a function and process buffered messages. Messages are sorted by timestamp asc. This operation resets the buffer so the same messages are not provided multiple times. * clear the buffer when sending a message (we expect interest to change then)
Original link refers to gatling.io/docs/current/. Actual docs location is docs.gatling.io
Motivation: Improve doc by using meaningful values Modifications: Replace dedicated host example values Result: Better doc for a better world
Motivation: Should be handled in the build plugins, not Gatling itself, in particular now that we've dropped the original bundle.
Motivation: The run description is passed as program arg in a forked process, so it can cause trouble if not encoded. We're going with Base64 (already committed in the maven plugin). The `Engine` class is still using plain as it doesn't fork a process.
Motivation: See gatling#4534 getCookieValue's parameters are no very clear (documentation) and behavior is not very intuitive for people who are not familiar with RFC6265. In particular, people would expect parameters to work as basic filter, in particular when unspecified. Modifications: * when path is undefined, always match instead of path matching on / * when secure is undefined, always match; when defined filter cookies whose attribute matches the value
slandelle
force-pushed
the
main
branch
2 times, most recently
from
April 15, 2024 21:06
07732f7
to
e244cdd
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 returning
Seq[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?