https://issues.apache.org/bugzilla/show_bug.cgi?id=54874
--- Comment #7 from Sebb <[email protected]> --- (In reply to Dan Fruehauf from comment #6) > (In reply to Sebb from comment #5) > > (In reply to Dan Fruehauf from comment #3) > > > (In reply to Sebb from comment #2) > > > > What advantage does using the device name give? > > > > Does it do anything other than choose the IP address for that device? > > > > > > The scenario I solved at the time - when submitting this patch was trying > > > to > > > create HTTP load via VPN devices with dynamically assigned addresses. > > > While > > > possible to regenerate the scenario every time VPN devices change > > > addresses, > > > I've found it cleaner to be able to assign devices in the scenario rather > > > than addresses. The script that fired up the VPN devices knew what devices > > > are going to come up, but the addresses would be assigned dynamically > > > every > > > time. The current behaviour of having a source IP address is still > > > preserved > > > after applying this patch. > > > > As a work-round, maybe you could use a property for the IP address and > > define the property on the command-line. > I could, but define 100 properties? The test case made use of many VPN > devices at the same time, not just one. It's still a possible work-round. > > > > But provided that the change does not affect any existing tests, I don't see > > why the field should not allow device names as well as host names. > > > > However, the current implementation always searches the device names first; > > I think that is wrong. This is because it takes time to search the > > interfaces and the device name will override a hostname. > By all means, behaviour may change if one has a hostname named as a device > name (tun0, tap250, eth11 etc.). This is a rather awkward situation when you > think about it. I do not know of a single person who names hostnames as > devices. But then still if he has a hostname (not interface) which resolves > for instance 'eth0' -> '192.168.0.1' and a device which is 'eth0' -> > '192.168.0.1', JMeter behaviour will not change if he entered 'eth0' in the > 'Source IP' field. Before the patch it would resolve to '192.168.0.1' by > using the hostname, while after it'll resolve as well to '192.168.0.1' using > the device name. > > If he has though a device 'eth0' -> '192.168.0.1' and hostname 'eth0' -> > '192.168.0.2', then yes, behaviour will change. Then we should ask ourselves > if we want to cater also for these stupid situations? I tend to say no. Sorry, but for backwards compatibility, host names must take precedence over device names. > > > > Perhaps just process the hostnames first - would that work? > Provided I do that, how do I know if something is a hostname or a device? If the name does not resolve as a host name, then assume it may be a device. > It > means that I'll have to use regular expressions to actually parse any device > type that's available on any unix system. So for instance if you put 'pony0' > as hostname and pony0 is a device of type pony in operating system ZooOS > (which is supported by JMeter), how do I decide if pony0 is a hostname or a > device? See above. > > > > Or maybe insist that device names always have the ipv[46]: prefix, or insist > > that they have a suffix that is not valid for a hostname - e.g. "eth0:" > That could work, but could also confuse users Why would it confuse users? So long as the documentation is clear, it would be less confusing than suddenly having a host name stop working because it happens to be the same as the name of an interface. > and significantly reduce the > usability of that feature IMO. The average user will just use "tun10". The average user won't even know that devices are supported unless they read the documentation. Surely the Unix device is actually something like /dev/tun10, not just "tun10" anyway? > After > not understanding why things work he'll either give up (most likely) or > search the documentation just to find out he needs the 'ipv4:' prefix. If the user fails to read the documentation, then they are likely to encounter all sorts of problems. -- You are receiving this mail because: You are the assignee for the bug.
