[Bug 60081] Interleave Controller is not synchronised across threads
https://bz.apache.org/bugzilla/show_bug.cgi?id=60081 --- Comment #8 from Felix Schumacher --- Comment on attachment 34320 --> https://bz.apache.org/bugzilla/attachment.cgi?id=34320 Patch implementing feature in a simpler way as per Felix proposal Looks a lot cleaner. I think the res strings are missing and I would prefer the modulo operator be separated with spaces from its operands. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 60081] Interleave Controller is not synchronised across threads
https://bz.apache.org/bugzilla/show_bug.cgi?id=60081 Philippe Mouawad changed: What|Removed |Added Attachment #34316|0 |1 is obsolete|| --- Comment #7 from Philippe Mouawad --- Created attachment 34320 --> https://bz.apache.org/bugzilla/attachment.cgi?id=34320&action=edit Patch implementing feature in a simpler way as per Felix proposal -- You are receiving this mail because: You are the assignee for the bug.
[Bug 60081] Interleave Controller is not synchronised across threads
https://bz.apache.org/bugzilla/show_bug.cgi?id=60081 --- Comment #6 from Philippe Mouawad --- Created attachment 34316 --> https://bz.apache.org/bugzilla/attachment.cgi?id=34316&action=edit Patch implementing interleave accross threads -- You are receiving this mail because: You are the assignee for the bug.
[Bug 60081] Interleave Controller is not synchronised across threads
https://bz.apache.org/bugzilla/show_bug.cgi?id=60081 Philippe Mouawad changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #5 from Philippe Mouawad --- (In reply to Wyatt Epp from comment #4) > (In reply to Philippe Mouawad from comment #3) > > Hi, > > Can I ask why you don't use RandomController in this case ? > > Lack of determinism is an issue (it's something that was stressed repeatedly > by the project lead). But the reason we discovered this in the first place > was by fixing the Weighted Switch Controller plugin to respect controllers > by deriving from InterleaveControl. > > It's a good idea, and I'll experiment with deriving from RandomController > instead (making it a Weighted Random Controller instead, I guess), but I > still think this is an issue in its own right. I am not sure. If you look at your initial request for Interleave accross threads, you take the hypothesis that threads run nearly sequentially while you have no guarantee on order , and as a consequence Interleave would end up generating the equivalent of RandomController. Unless I am missing something in your report or use case. > > > Another alternative is to use a Counter shared accross threads that varies > > between 1 and the number of children of the controller and use a Switch > > Controller. > > I guess this could work, but it's a rather ugly hack and I'm not fond of the > idea. This sort of circumlocution makes the controller abstraction feel > very leaky to me. I don't think it's ugly, SwitchController is done for that. I think it will show you that the interleave you expect is not respected; > > > The spike-like pattern has less chances to occur if using Random timers and > > if the Controller has samplers before and after it , so I am not sure it's a > > problem. > > Using random timers is the sort of hack that's going to seriously play havoc > with the consistency of transaction throughput, so it'll never fly with > people above me. It depend on your use case. When I simulate Real User behaviour, I use random timers, not using them seems to me a mistake. If you're more in a server to server call then ok. >But even if they were fine with it, I don't think it's > enough to work at every scale we need because the smoothing this introduces > is a function of thread count and delay range. > > > AFAIU, this Interleave Controller has always worked like this and I am > > afraid many users expect it to work like it does. > > I think it probably HAS always worked this way. I disagree that these > specific semantics are what any user might reasonably expect, though. (You > can sort of figure it out with a close read of the manual but I wouldn't > call it clear or obvious.) If anything, the way it works now has probably > driven people away from it (and is, I suspect, probably why the Weighted > Switch Controller inherited from GenericController instead of > InterleaveControl in the first place). It is hard to know usage of Controllers among community. > > I've been thinking about it a lot, but I haven't yet been able to come up > with any compelling reasons a user might want this pattern of interleaving > or wouldn't want evenly interleaved requests. I'm just one person, though; > maybe this is something that needs to be brought to more eyes? > > Thanks, > Wyatt Anyway I attached a patch, can you test it and see if that's what you expect ? Thanks -- You are receiving this mail because: You are the assignee for the bug.
[Bug 60081] Interleave Controller is not synchronised across threads
https://bz.apache.org/bugzilla/show_bug.cgi?id=60081 Wyatt Epp changed: What|Removed |Added Status|NEEDINFO|NEW --- Comment #4 from Wyatt Epp --- (In reply to Philippe Mouawad from comment #3) > Hi, > Can I ask why you don't use RandomController in this case ? Lack of determinism is an issue (it's something that was stressed repeatedly by the project lead). But the reason we discovered this in the first place was by fixing the Weighted Switch Controller plugin to respect controllers by deriving from InterleaveControl. It's a good idea, and I'll experiment with deriving from RandomController instead (making it a Weighted Random Controller instead, I guess), but I still think this is an issue in its own right. > Another alternative is to use a Counter shared accross threads that varies > between 1 and the number of children of the controller and use a Switch > Controller. I guess this could work, but it's a rather ugly hack and I'm not fond of the idea. This sort of circumlocution makes the controller abstraction feel very leaky to me. > The spike-like pattern has less chances to occur if using Random timers and > if the Controller has samplers before and after it , so I am not sure it's a > problem. Using random timers is the sort of hack that's going to seriously play havoc with the consistency of transaction throughput, so it'll never fly with people above me. But even if they were fine with it, I don't think it's enough to work at every scale we need because the smoothing this introduces is a function of thread count and delay range. > AFAIU, this Interleave Controller has always worked like this and I am > afraid many users expect it to work like it does. I think it probably HAS always worked this way. I disagree that these specific semantics are what any user might reasonably expect, though. (You can sort of figure it out with a close read of the manual but I wouldn't call it clear or obvious.) If anything, the way it works now has probably driven people away from it (and is, I suspect, probably why the Weighted Switch Controller inherited from GenericController instead of InterleaveControl in the first place). I've been thinking about it a lot, but I haven't yet been able to come up with any compelling reasons a user might want this pattern of interleaving or wouldn't want evenly interleaved requests. I'm just one person, though; maybe this is something that needs to be brought to more eyes? Thanks, Wyatt -- You are receiving this mail because: You are the assignee for the bug.
[Bug 60081] Interleave Controller is not synchronised across threads
https://bz.apache.org/bugzilla/show_bug.cgi?id=60081 Philippe Mouawad changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #3 from Philippe Mouawad --- Hi, Can I ask why you don't use RandomController in this case ? Another alternative is to use a Counter shared accross threads that varies between 1 and the number of children of the controller and use a Switch Controller. The spike-like pattern has less chances to occur if using Random timers and if the Controller has samplers before and after it , so I am not sure it's a problem. AFAIU, this Interleave Controller has always worked like this and I am afraid many users expect it to work like it does. I personnaly never used it so I cannot tell if it suits me or not :-) thoughts ? Thx -- You are receiving this mail because: You are the assignee for the bug.
[Bug 60081] Interleave Controller is not synchronised across threads
https://bz.apache.org/bugzilla/show_bug.cgi?id=60081 Philippe Mouawad changed: What|Removed |Added CC||p.mouawad@ubik-ingenierie.c ||om Severity|normal |enhancement -- You are receiving this mail because: You are the assignee for the bug.
[Bug 60081] Interleave Controller is not synchronised across threads
https://bz.apache.org/bugzilla/show_bug.cgi?id=60081 --- Comment #2 from Wyatt Epp --- (In reply to harsh from comment #1) > Hi, > > According to java doc, Interleave controller "Alternate among each of the > children controllers or samplers for each loop iteration". That's not at issue here. In fact, I was quite pleased that it honours the contract of tree semantics when it encounters controllers. The issue is when there are multiple threads, they all interleave the _SAME_ subcontrollers and samplers at the _SAME_ time. They're effectively in lockstep. This makes it unusable to generate a mixed load of multiple scenarios. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 60081] Interleave Controller is not synchronised across threads
https://bz.apache.org/bugzilla/show_bug.cgi?id=60081 --- Comment #1 from harsh --- Hi, According to java doc, Interleave controller "Alternate among each of the children controllers or samplers for each loop iteration". Also in component reference "If you add Generative or Logic Controllers to an Interleave Controller, JMeter will alternate among each of the other controllers for each loop iteration." So in this case behaviour is proper. as for each loop, it will interleave the samplers. -- You are receiving this mail because: You are the assignee for the bug.
