https://issues.apache.org/bugzilla/show_bug.cgi?id=54874
--- Comment #6 from Dan Fruehauf <[email protected]> --- (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. > > 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. > > 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? 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? > > 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 and significantly reduce the usability of that feature IMO. The average user will just use "tun10". 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. -- You are receiving this mail because: You are the assignee for the bug.
