> Introducing this is not easy as there is currently an assumption on code >that TestElement are cloned per thread/User
I know that. I know "controller processing" is super-obscure. Once I even tried to follow the logic behind TransactionController, but I gave up. On the other hand, implementing a "concurrent controller" rather than half-baked support for http samplers might look cleaner. A great success would be if "concurrent resource download" could leverage "concurrent controller" infrastructure. The difficult part is the semantics. Enabling concurrent writes to the "variables" would probably hurt. Think of 2 concurrent requests each of those use javascript pre-post processor. Having a dedicated set of variables for each "sub-thread" (e.g. copy-on-write) is good (they do not need to access each other's variables after all), however it would require some "merge" operation that will merge the results from the sub-threads and update "original variables" accordingly. The easiest way to merge is not doing that at all and require some user-given action to "propagate information from sub-thread to the original thread". <-- I'm sorry to braindump here. It looks like I'm copy&pasting things from "actor model". I'm not sure if that "memory model" was already thought through. >But of course if you feel like implementing this, it would be great :-) It is not the top priority for me, however the problem does exist, so I want to test the ground if that is feasible, or if that contradicts to the roadmap. >the issue here but more the "non random" order of calls, what's your >thoughts on this ? Well, JMeter invokes samples in more or less the order in which they were recorded. It does not mean they always come in that order, but in my experience the order of requests from browser is more or less predictable. Even "concurrent" requests are launched by a single-threaded javascript logic, thus the variance is not that high. Vladimir
