You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@jmeter.apache.org by bu...@apache.org on 2013/04/22 04:22:38 UTC
[Bug 54874] New: Support device in addition to source IP address
https://issues.apache.org/bugzilla/show_bug.cgi?id=54874
Bug ID: 54874
Summary: Support device in addition to source IP address
Product: JMeter
Version: unspecified
Hardware: All
OS: Linux
Status: NEW
Severity: enhancement
Priority: P2
Component: HTTP
Assignee: issues@jmeter.apache.org
Reporter: malkodan@gmail.com
Classification: Unclassified
Created attachment 30219
--> https://issues.apache.org/bugzilla/attachment.cgi?id=30219&action=edit
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.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 54874] Support device in addition to source IP address
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=54874
--- Comment #11 from Philippe Mouawad <p....@ubik-ingenierie.com> ---
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.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 54874] Support device in addition to source IP address
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=54874
--- Comment #3 from Dan Fruehauf <ma...@gmail.com> ---
(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.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 54874] Support device in addition to source IP address
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=54874
Sebb <se...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO
--- Comment #2 from Sebb <se...@apache.org> ---
What advantage does using the device name give?
Does it do anything other than choose the IP address for that device?
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 54874] Support device in addition to source IP address
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=54874
Philippe Mouawad <p....@ubik-ingenierie.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |PatchAvailable
CC| |p.mouawad@ubik-ingenierie.c
| |om
OS|Linux |All
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 54874] Support device in addition to source IP address
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=54874
--- Comment #15 from Sebb <se...@apache.org> ---
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
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 54874] Support device in addition to source IP address
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=54874
Sebb <se...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |RESOLVED
Resolution|--- |FIXED
--- Comment #12 from Sebb <se...@apache.org> ---
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
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 54874] Support device in addition to source IP address
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=54874
--- Comment #8 from Dan Fruehauf <ma...@gmail.com> ---
(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.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 54874] Support device in addition to source IP address
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=54874
--- Comment #1 from Philippe Mouawad <p....@ubik-ingenierie.com> ---
Sounds weird to use same field for ip and device.
Gui is already overwhelmed so not sure we should add this one.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 54874] Support device in addition to source IP address
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=54874
--- Comment #7 from Sebb <se...@apache.org> ---
(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.
[Bug 54874] Support device in addition to source IP address
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=54874
--- Comment #10 from Dan Fruehauf <ma...@gmail.com> ---
(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.
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 54874] Support device in addition to source IP address
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=54874
--- Comment #5 from Sebb <se...@apache.org> ---
(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:"
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 54874] Support device in addition to source IP address
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=54874
--- Comment #13 from Sebb <se...@apache.org> ---
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
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 54874] Support device in addition to source IP address
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=54874
--- Comment #6 from Dan Fruehauf <ma...@gmail.com> ---
(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.
[Bug 54874] Support device in addition to source IP address
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=54874
--- Comment #14 from Milamber <mi...@apache.org> ---
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
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 54874] Support device in addition to source IP address
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=54874
--- Comment #9 from Sebb <se...@apache.org> ---
(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
--
You are receiving this mail because:
You are the assignee for the bug.
[Bug 54874] Support device in addition to source IP address
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=54874
--- Comment #4 from Dan Fruehauf <ma...@gmail.com> ---
(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.
--
You are receiving this mail because:
You are the assignee for the bug.