Is there an idiom for repeating a block until a feeder is empty, feed()ing for each iteration? I’ve come up with something like this:
…
asLongAs(feeder.hasNext) {
feed(feeder)
…
}
Is that fine or is there a better approach? I’m trying to avoid “Feeder is now empty, stopping engine” errors. When the feeder is empty, the scenario should simply continue. At the same time I don’t want to need to know the size of the feeder in advance, otherwise I could just use repeat(). I’m streaming possibly very large JSON documents through a custom feeder, one object at a time, without loading them all in memory at once, so I don’t know how many there are in advance (it would be possible to encode the size in the very beginning of the JSON source, of course).
Is there a specific requirement that calls for feeders to return Map[String, String] instead of Map[String, Any]? Since the results are injected into the current user session and the session is essentially Map[String, Any]. It would be nice to be able to inject more than just Strings into the session from a feeder.
There’s currently no built-in for what you’re trying to achieve (might be a good idea to have one though).
The limitation with your implementation is that you use your feeder in 2 different actors: the one in charge of the loop and the one in charge of your feed, so your custom feeder has to be thread-safe, which will have an impact on performance.
I’ll try to come with a solution, but I won’t be able to work on it before a few days.
Until then, please notice that if your feeder runs out, the simulation will stop abruptly but the simulation.log file is not lost and you can still generate the reports with the -ro option.
There’s currently no built-in for what you’re trying to achieve (might be a good idea to have one though).
The limitation with your implementation is that you use your feeder in 2 different actors: the one in charge of the loop and the one in charge of your feed, so your custom feeder has to be thread-safe, which will have an impact on performance.
I’ll try to come with a solution, but I won’t be able to work on it before a few days.
Thanks for considering it, no rush!
Until then, please notice that if your feeder runs out, the simulation will stop abruptly but the simulation.log file is not lost and you can still generate the reports with the -ro option.
Are you sure that you hit a limitation with Feeders being based on Map[String, String]?
As Map is covariant in value type, if I change from Map[String, String] to Map[String, Any], people who have been using the current signature will have to downcast when popping a record.
I hit it when I wanted to put some arrays/lists into the session from a feeder. In other words, the problem exists under these circumstances:
You want to construct a request body from session information which is aggregated from multiple feeders.
A single feeder doesn’t have access to all the data to construct the request body itself as a string, because it doesn’t have access to the session (i.e. it would need session data put in previously by another feeder).
So you end up with the idea of just putting the data structures into the session from each feeder and do the request body construction in another step that has access to the full session. That doesn’t work because the feeder must return strings.
So basically, the problem is a result of the precondition that feeders don’t have access to the session, which seemed fine to me but I didn’t see the obvious reason for only returning strings from feeders as that stuff is just put into the session.
Of course the described scenario implies that you have some more structured/nested data you’re parsing in the feeder, not just strings in which case it works just fine.