Created attachment 30219 [details] Patch to fix HTTPSampler and accept also a device in the 'Source IP address' box Overview: Currently HTTPSampler supports only source IP addresses in the 'Source IP address' box, to allow testing from various different IP addresses on the same machine. It doesn't support however entering a device, for instance eth0, eth1, tun0 etc Steps to Reproduce: 1. Enter a device in the 'Source IP address' box instead of an IP address Actual Results: The main IP address of the machine is being used Expected Results: The device address should be used. Additional Information: The following patch fixed the behaviour and allows entering a device and not only an IP address.
Sounds weird to use same field for ip and device. Gui is already overwhelmed so not sure we should add this one.
What advantage does using the device name give? Does it do anything other than choose the IP address for that device?
(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.
(In reply to Philippe Mouawad from comment #1) > Sounds weird to use same field for ip and device. > Gui is already overwhelmed so not sure we should add this one. I agree the GUI is already overwhelmed, however the previous behaviour remains with the additional option of specifying a device instead of only a source address.
(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. 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. Perhaps just process the hostnames first - would that work? 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:"
(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.
(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.
(In reply to Sebb from comment #7) > (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. I understand the backward compatibility argument, however you are catering here for the an extremely unlikely use case, which probably doesn't exist and will happen if and only if both conditions are met: * The user has a hostname named as a device - UNLIKELY * That hostname resolves to an IP address which is not of the mentioned device - VERY VERY UNLIKELY > > > > > > > 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. You are adding significantly extra complexity here for a situation that probably doesn't happen. Over engineering backward compatibility. > > > 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? No, it's just 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. > > If the user fails to read the documentation, then they are likely to > encounter all sorts of problems. On the other hand you are trying to address in this argument a use case likely to happen if the user's intelligence level is too low to even learn how to read. I'm unconvinced that any of the hypothetical scenarios we mentioned here actually happen in real life. Even with pretty bad engineering paradigms.
(In reply to Dan Fruehauf from comment #8) > I understand the backward compatibility argument, however you are catering > here for the an extremely unlikely use case, which probably doesn't exist > and will happen if and only if both conditions are met: > * The user has a hostname named as a device - UNLIKELY > * That hostname resolves to an IP address which is not of the mentioned > device - VERY VERY UNLIKELY But not impossible. > > > > > > > > > > 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. > > You are adding significantly extra complexity here for a situation that > probably doesn't happen. Over engineering backward compatibility. I disagree that any of the fixes I proposed would significantly increase the complexity. > > Surely the Unix device is actually something like /dev/tun10, not just > > "tun10" anyway? > No, it's just tun10. So it does not exist under /dev? > I'm unconvinced that any of the hypothetical scenarios we mentioned here > actually happen in real life. Even with pretty bad engineering paradigms. We disagree. The patch will not be accepted without changes to ensure: - host names take precedence over device names - the network devices are not searched unnecessarily
(In reply to Sebb from comment #9) > (In reply to Dan Fruehauf from comment #8) > > I understand the backward compatibility argument, however you are catering > > here for the an extremely unlikely use case, which probably doesn't exist > > and will happen if and only if both conditions are met: > > * The user has a hostname named as a device - UNLIKELY > > * That hostname resolves to an IP address which is not of the mentioned > > device - VERY VERY UNLIKELY > > But not impossible. Prove me wrong. > > > > > > > > > > > > > > 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. > > > > You are adding significantly extra complexity here for a situation that > > probably doesn't happen. Over engineering backward compatibility. > > I disagree that any of the fixes I proposed would significantly increase the > complexity. > > > > Surely the Unix device is actually something like /dev/tun10, not just > > > "tun10" anyway? > > No, it's just tun10. > > So it does not exist under /dev? > > > I'm unconvinced that any of the hypothetical scenarios we mentioned here > > actually happen in real life. Even with pretty bad engineering paradigms. > > We disagree. Prove me wrong then. > > The patch will not be accepted without changes to ensure: > - host names take precedence over device names > - the network devices are not searched unnecessarily If the JMeter team prefers backward compatibility for hypothetical, unlikely, probably non-existent scenarios over innovation (which solves real world scenarios) then I think my work here is done. Feel free to close that bug.
Backward compatibility is important, performance and reliability are also concerned here. The initial patch introduces performance issue anyway so it cannot be integrated as is. Also resolving host before device does not seems the best option to me. In my opinion it should be a choice of user either with checkbox or with a jmeter property, introduce a Resolver interface and use could choose: - hostresolver - deviceresolver - ... Anyway it is not very kind to say we prefer backward compatibility to innovation, but I will remain silent and let new features talk.
URL: http://svn.apache.org/r1511542 Log: Support device in addition to source IP address Bugzilla Id: 54874 Modified: jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPAbstractImpl.java jmeter/trunk/xdocs/changes.xml jmeter/trunk/xdocs/usermanual/component_reference.xml
URL: http://svn.apache.org/r1511681 Log: Support device in addition to source IP address Support choice of IPv4 or IPv6; report error if selected interface is not found Bugzilla Id: 54874 Modified: jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPAbstractImpl.java jmeter/trunk/xdocs/usermanual/component_reference.xml
URL: http://svn.apache.org/r1513685 Log: Re-organizes the Source Address options. Change the organization for "Optional tasks" in the HTTP Request (separating into 3 sub-blocks : Embedded resources, Source Address, Optional tasks) Bugzilla Id: 54874 Modified: jmeter/trunk/src/core/org/apache/jmeter/resources/messages.properties jmeter/trunk/src/core/org/apache/jmeter/resources/messages_es.properties jmeter/trunk/src/core/org/apache/jmeter/resources/messages_fr.properties jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/control/gui/HttpTestSampleGui.java jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPAbstractImpl.java jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPSamplerBase.java jmeter/trunk/xdocs/usermanual/component_reference.xml URL: http://svn.apache.org/r1513743 Log: Fix an issue with localization in Source Address Type list Bugzilla Id: 54874 Modified: jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPSamplerBase.java
URL: http://svn.apache.org/r1513863 Log: Support device in addition to source IP address Use enum for source types; don't convert between index and name unnecessarily. Bugzilla Id: 54874 Modified: jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/control/gui/HttpTestSampleGui.java jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPAbstractImpl.java jmeter/trunk/src/protocol/http/org/apache/jmeter/protocol/http/sampler/HTTPSamplerBase.java
This issue has been migrated to GitHub: https://github.com/apache/jmeter/issues/3106