You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Amir Malekpour (JIRA)" <ji...@apache.org> on 2011/06/06 19:18:59 UTC
[jira] [Created] (AMQ-3359) UDP Transport connector listens on a
random port number
UDP Transport connector listens on a random port number
-------------------------------------------------------
Key: AMQ-3359
URL: https://issues.apache.org/jira/browse/AMQ-3359
Project: ActiveMQ
Issue Type: Bug
Components: Broker
Affects Versions: 5.5.0, 5.4.2, 5.4.1, 5.4.0
Reporter: Amir Malekpour
The broker listens on a random UDP port number instead of the one configure in the URI. The port number changes each time the broker is restarted. However, the management console indicates that the broker's listening on the configured port number but netstat shows another UDP port number. The reason is that as seen in the
following block, the UdpTransport constructor does not read this.port from remoreLocation and only reads its address and leaves it to be zero. The solution is to add this line: this.port = remoteLocation.getPort();
public UdpTransport(OpenWireFormat wireFormat, URI remoteLocation) throws UnknownHostException, IOException {
this(wireFormat);
this.targetAddress = createAddress(remoteLocation);
description = remoteLocation.toString() + "@";
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (AMQ-3359) UDP Transport connector
listens on a random port number
Posted by "Christian Posta (Issue Comment Edited) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13182602#comment-13182602 ]
Christian Posta edited comment on AMQ-3359 at 1/9/12 4:26 PM:
--------------------------------------------------------------
Amir,
The unit tests to which Tim refers do indeed break when applying the patch you created, as they are intended. As it appears, the different constructors in the UdpTransport class are intended for different uses. The constructor on which you made you changes is intended by the client transport creation. Which means, as you pointed out, there must be a bug because the server code is calling that constructor intended for the client. I have written a simple test to demonstrate the error, and the patch I added to the JIRA fixes the issue. Strangely, this issue's fix is related to the issue seen here: AMQ-3275. For that JIRA, a patch was committed to the trunk (http://svn.apache.org/viewvc?view=revision&revision=1089864), but it appears that patch was never merged in to any release versions. Tim, maybe you can see why that is. In any event, I've submitted my code anyway as a patch which adds comments and cleans up the code a little bit. See UdpTransportBindTest.java for a simple integration test that shows the connection broken and working before/after applying the patch.
was (Author: ceposta):
Amir,
The unit tests to which Tim refers do indeed break when applying the patch you created, as they are intended. As it appears, the different constructors in the UdpTransport class are intended for different uses. The constructor on which you made you changes are intended by the client transport creation. Which means, as you pointed out, there must be a bug because the server code is calling that constructor intended for the client. I have written a simple test to demonstrate the error, and the patch I added to the JIRA fixes the issue. Strangely, this issue's fix is related to the issue seen here: AMQ-3275. For that JIRA, a patch was committed to the trunk (http://svn.apache.org/viewvc?view=revision&revision=1089864), but it appears that patch was never merged in to any release versions. Tim, maybe you can see why that is. In any event, I've submitted my code anyway as a patch which adds comments and cleans up the code a little bit. See UdpTransportBindTest.java for a simple integration tests that shows the connection broken and working before/after applying the patch.
> UDP Transport connector listens on a random port number
> -------------------------------------------------------
>
> Key: AMQ-3359
> URL: https://issues.apache.org/jira/browse/AMQ-3359
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.4.0, 5.4.1, 5.4.2, 5.5.0
> Reporter: Amir Malekpour
> Labels: broker, port, transport, udp
> Attachments: AMQ-3359.patch, AMQ-3359.patch, UpdTransportBindTest.java
>
> Original Estimate: 5m
> Remaining Estimate: 5m
>
> The broker listens on a random UDP port number instead of the one configure in the URI. The port number changes each time the broker is restarted. However, the management console indicates that the broker's listening on the configured port number while it is not the case (netstat shows another UDP port number). The reason is that (as seen in the following block) the UdpTransport constructor does not assign "this.port" from remoteLocation but only reads the address and leaves "this.port" to be zero. Subsequently, Java API picks any available port number when it is creating the DatagraSocket. The solution is to add this line: "this.port = remoteLocation.getPort();" to the following constructor as seen in the accompanying patch.
> public UdpTransport(OpenWireFormat wireFormat, URI remoteLocation) throws UnknownHostException, IOException {
> this(wireFormat);
> this.targetAddress = createAddress(remoteLocation);
> description = remoteLocation.toString() + "@";
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQ-3359) UDP Transport connector listens on a
random port number
Posted by "Amir Malekpour (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Amir Malekpour updated AMQ-3359:
--------------------------------
Description:
The broker listens on a random UDP port number instead of the one configure in the URI. The port number changes each time the broker is restarted. However, the management console indicates that the broker's listening on the configured port number but netstat shows another UDP port number. The reason is that as seen in the
following block, the UdpTransport constructor does not read this.port from remoreLocation and only reads its address and leaves the this.port to be zero. The solution is to add this line: this.port = remoteLocation.getPort();
public UdpTransport(OpenWireFormat wireFormat, URI remoteLocation) throws UnknownHostException, IOException {
this(wireFormat);
this.targetAddress = createAddress(remoteLocation);
description = remoteLocation.toString() + "@";
}
was:
The broker listens on a random UDP port number instead of the one configure in the URI. The port number changes each time the broker is restarted. However, the management console indicates that the broker's listening on the configured port number but netstat shows another UDP port number. The reason is that as seen in the
following block, the UdpTransport constructor does not read this.port from remoreLocation and only reads its address and leaves it to be zero. The solution is to add this line: this.port = remoteLocation.getPort();
public UdpTransport(OpenWireFormat wireFormat, URI remoteLocation) throws UnknownHostException, IOException {
this(wireFormat);
this.targetAddress = createAddress(remoteLocation);
description = remoteLocation.toString() + "@";
}
> UDP Transport connector listens on a random port number
> -------------------------------------------------------
>
> Key: AMQ-3359
> URL: https://issues.apache.org/jira/browse/AMQ-3359
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.4.0, 5.4.1, 5.4.2, 5.5.0
> Reporter: Amir Malekpour
> Labels: broker, port, transport, udp
> Original Estimate: 1m
> Remaining Estimate: 1m
>
> The broker listens on a random UDP port number instead of the one configure in the URI. The port number changes each time the broker is restarted. However, the management console indicates that the broker's listening on the configured port number but netstat shows another UDP port number. The reason is that as seen in the
> following block, the UdpTransport constructor does not read this.port from remoreLocation and only reads its address and leaves the this.port to be zero. The solution is to add this line: this.port = remoteLocation.getPort();
> public UdpTransport(OpenWireFormat wireFormat, URI remoteLocation) throws UnknownHostException, IOException {
> this(wireFormat);
> this.targetAddress = createAddress(remoteLocation);
> description = remoteLocation.toString() + "@";
> }
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-3359) UDP Transport connector listens on a
random port number
Posted by "Christian Posta (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13182607#comment-13182607 ]
Christian Posta commented on AMQ-3359:
--------------------------------------
sorry for the many updates and comments, but i have one more. my patch was written against the 5.4.3 tag
> UDP Transport connector listens on a random port number
> -------------------------------------------------------
>
> Key: AMQ-3359
> URL: https://issues.apache.org/jira/browse/AMQ-3359
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.4.0, 5.4.1, 5.4.2, 5.5.0
> Reporter: Amir Malekpour
> Labels: broker, port, transport, udp
> Attachments: AMQ-3359.patch, AMQ-3359.patch, UpdTransportBindTest.java
>
> Original Estimate: 5m
> Remaining Estimate: 5m
>
> The broker listens on a random UDP port number instead of the one configure in the URI. The port number changes each time the broker is restarted. However, the management console indicates that the broker's listening on the configured port number while it is not the case (netstat shows another UDP port number). The reason is that (as seen in the following block) the UdpTransport constructor does not assign "this.port" from remoteLocation but only reads the address and leaves "this.port" to be zero. Subsequently, Java API picks any available port number when it is creating the DatagraSocket. The solution is to add this line: "this.port = remoteLocation.getPort();" to the following constructor as seen in the accompanying patch.
> public UdpTransport(OpenWireFormat wireFormat, URI remoteLocation) throws UnknownHostException, IOException {
> this(wireFormat);
> this.targetAddress = createAddress(remoteLocation);
> description = remoteLocation.toString() + "@";
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQ-3359) UDP Transport connector listens on a
random port number
Posted by "Christian Posta (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christian Posta updated AMQ-3359:
---------------------------------
Attachment: UpdTransportBindTest.java
> UDP Transport connector listens on a random port number
> -------------------------------------------------------
>
> Key: AMQ-3359
> URL: https://issues.apache.org/jira/browse/AMQ-3359
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.4.0, 5.4.1, 5.4.2, 5.5.0
> Reporter: Amir Malekpour
> Labels: broker, port, transport, udp
> Attachments: AMQ-3359.patch, AMQ-3359.patch, UpdTransportBindTest.java
>
> Original Estimate: 5m
> Remaining Estimate: 5m
>
> The broker listens on a random UDP port number instead of the one configure in the URI. The port number changes each time the broker is restarted. However, the management console indicates that the broker's listening on the configured port number while it is not the case (netstat shows another UDP port number). The reason is that (as seen in the following block) the UdpTransport constructor does not assign "this.port" from remoteLocation but only reads the address and leaves "this.port" to be zero. Subsequently, Java API picks any available port number when it is creating the DatagraSocket. The solution is to add this line: "this.port = remoteLocation.getPort();" to the following constructor as seen in the accompanying patch.
> public UdpTransport(OpenWireFormat wireFormat, URI remoteLocation) throws UnknownHostException, IOException {
> this(wireFormat);
> this.targetAddress = createAddress(remoteLocation);
> description = remoteLocation.toString() + "@";
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (AMQ-3359) UDP Transport connector
listens on a random port number
Posted by "Amir Malekpour (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13091760#comment-13091760 ]
Amir Malekpour edited comment on AMQ-3359 at 9/5/11 3:34 PM:
-------------------------------------------------------------
Well, I have to disagree with you on this. I even resorted to "println" to make sure the method that is called IS the one I've mentioned above. (Even if it wasn't this is clearly a bug in that method to ignore the provided port number, so ignoring the buggy method on the basis that it's not called does not seem sound to me, though as I sad it is called).
Now as for a case that proves the existence of the bug, just run the broker with UDP transport and use netstat to check if the broker is actually listening on the specified port. You'll see that it isn't. Honestly, if this is not a convincing case I don't know what is.
was (Author: amir.malekpour):
Well, I have to disagree with you on this. I even resorted to "println" to make sure the method that is called IS the one
I've mentioned above. (Even if it wasn't this is clearly a bug in that method to ignore the provided port number, so ignoring the bug on the basis that its' not called does not seem sound to me, though as I sad it is called).
Now as for a case that proves the existence of the bug, just run the broker with UDP transport and use netstat to check if the broker is actually listening on the specified port. You'll see that it isn't. Honestly, if this is not a convincing case I don't know what is.
> UDP Transport connector listens on a random port number
> -------------------------------------------------------
>
> Key: AMQ-3359
> URL: https://issues.apache.org/jira/browse/AMQ-3359
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.4.0, 5.4.1, 5.4.2, 5.5.0
> Reporter: Amir Malekpour
> Labels: broker, port, transport, udp
> Attachments: AMQ-3359.patch
>
> Original Estimate: 5m
> Remaining Estimate: 5m
>
> The broker listens on a random UDP port number instead of the one configure in the URI. The port number changes each time the broker is restarted. However, the management console indicates that the broker's listening on the configured port number while it is not the case (netstat shows another UDP port number). The reason is that (as seen in the following block) the UdpTransport constructor does not assign "this.port" from remoteLocation but only reads the address and leaves "this.port" to be zero. Subsequently, Java API picks any available port number when it is creating the DatagraSocket. The solution is to add this line: "this.port = remoteLocation.getPort();" to the following constructor as seen in the accompanying patch.
> public UdpTransport(OpenWireFormat wireFormat, URI remoteLocation) throws UnknownHostException, IOException {
> this(wireFormat);
> this.targetAddress = createAddress(remoteLocation);
> description = remoteLocation.toString() + "@";
> }
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (AMQ-3359) UDP Transport connector
listens on a random port number
Posted by "Amir Malekpour (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13095922#comment-13095922 ]
Amir Malekpour edited comment on AMQ-3359 at 9/5/11 3:33 PM:
-------------------------------------------------------------
Well, I have to disagree with you on this. I even resorted to "println" to make sure the method that is called IS the one I've mentioned above. (Even if it wasn't this is clearly a bug in that method to ignore the provided port number, so ignoring the buggy method on the basis that it's not called does not seem sound to me, though as I sad it is called).
Now as for a case that proves the existence of the bug, just run the broker with UDP transport and use netstat to check if the broker is actually listening on the specified port. You'll see that it isn't. Honestly, if this is not a convincing case I don't know what is.
was (Author: amir.malekpour):
Well, I have to disagree with you on this. I even resorted to "println" to make sure the method that is called IS the one I've mentioned above. (Even if it wasn't this is clearly a bug in that method to ignore the provided port number, so ignoring the bug on the basis that its' not called does not seem sound to me, though as I sad it is called).
Now as for a case that proves the existence of the bug, just run the broker with UDP transport and use netstat to check if the broker is actually listening on the specified port. You'll see that it isn't. Honestly, if this is not a convincing case I don't know what is.
> UDP Transport connector listens on a random port number
> -------------------------------------------------------
>
> Key: AMQ-3359
> URL: https://issues.apache.org/jira/browse/AMQ-3359
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.4.0, 5.4.1, 5.4.2, 5.5.0
> Reporter: Amir Malekpour
> Labels: broker, port, transport, udp
> Attachments: AMQ-3359.patch
>
> Original Estimate: 5m
> Remaining Estimate: 5m
>
> The broker listens on a random UDP port number instead of the one configure in the URI. The port number changes each time the broker is restarted. However, the management console indicates that the broker's listening on the configured port number while it is not the case (netstat shows another UDP port number). The reason is that (as seen in the following block) the UdpTransport constructor does not assign "this.port" from remoteLocation but only reads the address and leaves "this.port" to be zero. Subsequently, Java API picks any available port number when it is creating the DatagraSocket. The solution is to add this line: "this.port = remoteLocation.getPort();" to the following constructor as seen in the accompanying patch.
> public UdpTransport(OpenWireFormat wireFormat, URI remoteLocation) throws UnknownHostException, IOException {
> this(wireFormat);
> this.targetAddress = createAddress(remoteLocation);
> description = remoteLocation.toString() + "@";
> }
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (AMQ-3359) UDP Transport connector listens on a
random port number
Posted by "Timothy Bish (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Timothy Bish closed AMQ-3359.
-----------------------------
Resolution: Not A Problem
Some testing seems to indicate that this is working as expected. Reopen if you can provide a test case the demonstrates the problem.
> UDP Transport connector listens on a random port number
> -------------------------------------------------------
>
> Key: AMQ-3359
> URL: https://issues.apache.org/jira/browse/AMQ-3359
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.4.0, 5.4.1, 5.4.2, 5.5.0
> Reporter: Amir Malekpour
> Labels: broker, port, transport, udp
> Attachments: AMQ-3359.patch
>
> Original Estimate: 5m
> Remaining Estimate: 5m
>
> The broker listens on a random UDP port number instead of the one configure in the URI. The port number changes each time the broker is restarted. However, the management console indicates that the broker's listening on the configured port number while it is not the case (netstat shows another UDP port number). The reason is that (as seen in the following block) the UdpTransport constructor does not assign "this.port" from remoteLocation but only reads the address and leaves "this.port" to be zero. Subsequently, Java API picks any available port number when it is creating the DatagraSocket. The solution is to add this line: "this.port = remoteLocation.getPort();" to the following constructor as seen in the accompanying patch.
> public UdpTransport(OpenWireFormat wireFormat, URI remoteLocation) throws UnknownHostException, IOException {
> this(wireFormat);
> this.targetAddress = createAddress(remoteLocation);
> description = remoteLocation.toString() + "@";
> }
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-3359) UDP Transport connector listens on a
random port number
Posted by "Christian Posta (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13182602#comment-13182602 ]
Christian Posta commented on AMQ-3359:
--------------------------------------
Amir,
The unit tests to which Tim refers do indeed break when applying the patch you created, as they are intended. As it appears, the different constructors in the UdpTransport class are intended for different uses. The constructor on which you made you changes are intended by the client transport creation. Which means, as you pointed out, there must be a bug because the server code is calling that constructor intended for the client. I have written a simple test to demonstrate the error, and the patch I added to the JIRA fixes the issue. Strangely, this issue's fix is related to the issue seen here: AMQ-3275. For that JIRA, a patch was committed to the trunk (http://svn.apache.org/viewvc?view=revision&revision=1089864), but it appears that patch was never merged in to any release versions. Tim, maybe you can see why that is. In any event, I've submitted my code anyway as a patch which adds comments and cleans up the code a little bit. See UdpTransportBindTest.java for a simple integration tests that shows the connection broken and working before/after applying the patch.
> UDP Transport connector listens on a random port number
> -------------------------------------------------------
>
> Key: AMQ-3359
> URL: https://issues.apache.org/jira/browse/AMQ-3359
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.4.0, 5.4.1, 5.4.2, 5.5.0
> Reporter: Amir Malekpour
> Labels: broker, port, transport, udp
> Attachments: AMQ-3359.patch
>
> Original Estimate: 5m
> Remaining Estimate: 5m
>
> The broker listens on a random UDP port number instead of the one configure in the URI. The port number changes each time the broker is restarted. However, the management console indicates that the broker's listening on the configured port number while it is not the case (netstat shows another UDP port number). The reason is that (as seen in the following block) the UdpTransport constructor does not assign "this.port" from remoteLocation but only reads the address and leaves "this.port" to be zero. Subsequently, Java API picks any available port number when it is creating the DatagraSocket. The solution is to add this line: "this.port = remoteLocation.getPort();" to the following constructor as seen in the accompanying patch.
> public UdpTransport(OpenWireFormat wireFormat, URI remoteLocation) throws UnknownHostException, IOException {
> this(wireFormat);
> this.targetAddress = createAddress(remoteLocation);
> description = remoteLocation.toString() + "@";
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQ-3359) UDP Transport connector listens on a
random port number
Posted by "Amir Malekpour (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Amir Malekpour updated AMQ-3359:
--------------------------------
Remaining Estimate: 5m (was: 1m)
Original Estimate: 5m (was: 1m)
> UDP Transport connector listens on a random port number
> -------------------------------------------------------
>
> Key: AMQ-3359
> URL: https://issues.apache.org/jira/browse/AMQ-3359
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.4.0, 5.4.1, 5.4.2, 5.5.0
> Reporter: Amir Malekpour
> Labels: broker, port, transport, udp
> Attachments: AMQ-3359.patch
>
> Original Estimate: 5m
> Remaining Estimate: 5m
>
> The broker listens on a random UDP port number instead of the one configure in the URI. The port number changes each time the broker is restarted. However, the management console indicates that the broker's listening on the configured port number but netstat shows another UDP port number. The reason is that as seen in the
> following block, the UdpTransport constructor does not read this.port from remoreLocation and only reads its address and leaves the this.port to be zero. The solution is to add this line: this.port = remoteLocation.getPort();
> public UdpTransport(OpenWireFormat wireFormat, URI remoteLocation) throws UnknownHostException, IOException {
> this(wireFormat);
> this.targetAddress = createAddress(remoteLocation);
> description = remoteLocation.toString() + "@";
> }
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQ-3359) UDP Transport connector listens on a
random port number
Posted by "Christian Posta (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christian Posta updated AMQ-3359:
---------------------------------
Attachment: AMQ-3359.patch
> UDP Transport connector listens on a random port number
> -------------------------------------------------------
>
> Key: AMQ-3359
> URL: https://issues.apache.org/jira/browse/AMQ-3359
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.4.0, 5.4.1, 5.4.2, 5.5.0
> Reporter: Amir Malekpour
> Labels: broker, port, transport, udp
> Attachments: AMQ-3359.patch, AMQ-3359.patch, UpdTransportBindTest.java
>
> Original Estimate: 5m
> Remaining Estimate: 5m
>
> The broker listens on a random UDP port number instead of the one configure in the URI. The port number changes each time the broker is restarted. However, the management console indicates that the broker's listening on the configured port number while it is not the case (netstat shows another UDP port number). The reason is that (as seen in the following block) the UdpTransport constructor does not assign "this.port" from remoteLocation but only reads the address and leaves "this.port" to be zero. Subsequently, Java API picks any available port number when it is creating the DatagraSocket. The solution is to add this line: "this.port = remoteLocation.getPort();" to the following constructor as seen in the accompanying patch.
> public UdpTransport(OpenWireFormat wireFormat, URI remoteLocation) throws UnknownHostException, IOException {
> this(wireFormat);
> this.targetAddress = createAddress(remoteLocation);
> description = remoteLocation.toString() + "@";
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (AMQ-3359) UDP Transport connector listens on a
random port number
Posted by "Timothy Bish (Closed) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Timothy Bish closed AMQ-3359.
-----------------------------
Resolution: Cannot Reproduce
Added the supplied test case to trunk, test passes.
> UDP Transport connector listens on a random port number
> -------------------------------------------------------
>
> Key: AMQ-3359
> URL: https://issues.apache.org/jira/browse/AMQ-3359
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.4.0, 5.4.1, 5.4.2, 5.5.0
> Reporter: Amir Malekpour
> Labels: broker, port, transport, udp
> Attachments: AMQ-3359.patch, AMQ-3359.patch, UpdTransportBindTest.java
>
> Original Estimate: 5m
> Remaining Estimate: 5m
>
> The broker listens on a random UDP port number instead of the one configure in the URI. The port number changes each time the broker is restarted. However, the management console indicates that the broker's listening on the configured port number while it is not the case (netstat shows another UDP port number). The reason is that (as seen in the following block) the UdpTransport constructor does not assign "this.port" from remoteLocation but only reads the address and leaves "this.port" to be zero. Subsequently, Java API picks any available port number when it is creating the DatagraSocket. The solution is to add this line: "this.port = remoteLocation.getPort();" to the following constructor as seen in the accompanying patch.
> public UdpTransport(OpenWireFormat wireFormat, URI remoteLocation) throws UnknownHostException, IOException {
> this(wireFormat);
> this.targetAddress = createAddress(remoteLocation);
> description = remoteLocation.toString() + "@";
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQ-3359) UDP Transport connector listens on a
random port number
Posted by "Amir Malekpour (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Amir Malekpour updated AMQ-3359:
--------------------------------
Attachment: AMQ-3359.patch
> UDP Transport connector listens on a random port number
> -------------------------------------------------------
>
> Key: AMQ-3359
> URL: https://issues.apache.org/jira/browse/AMQ-3359
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.4.0, 5.4.1, 5.4.2, 5.5.0
> Reporter: Amir Malekpour
> Labels: broker, port, transport, udp
> Attachments: AMQ-3359.patch
>
> Original Estimate: 1m
> Remaining Estimate: 1m
>
> The broker listens on a random UDP port number instead of the one configure in the URI. The port number changes each time the broker is restarted. However, the management console indicates that the broker's listening on the configured port number but netstat shows another UDP port number. The reason is that as seen in the
> following block, the UdpTransport constructor does not read this.port from remoreLocation and only reads its address and leaves the this.port to be zero. The solution is to add this line: this.port = remoteLocation.getPort();
> public UdpTransport(OpenWireFormat wireFormat, URI remoteLocation) throws UnknownHostException, IOException {
> this(wireFormat);
> this.targetAddress = createAddress(remoteLocation);
> description = remoteLocation.toString() + "@";
> }
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-3359) UDP Transport connector listens on a
random port number
Posted by "Timothy Bish (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13059944#comment-13059944 ]
Timothy Bish commented on AMQ-3359:
-----------------------------------
After some further investigation this doesn't seem to be an issue. The broker doesn't call the constructor that's referenced in this issue when it creates its transport server, it calls the Constructor taking a wireFormat and port number to bind to. The constructor referenced uses the remoteLocation address to connect to the broker as expected.
> UDP Transport connector listens on a random port number
> -------------------------------------------------------
>
> Key: AMQ-3359
> URL: https://issues.apache.org/jira/browse/AMQ-3359
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.4.0, 5.4.1, 5.4.2, 5.5.0
> Reporter: Amir Malekpour
> Labels: broker, port, transport, udp
> Attachments: AMQ-3359.patch
>
> Original Estimate: 5m
> Remaining Estimate: 5m
>
> The broker listens on a random UDP port number instead of the one configure in the URI. The port number changes each time the broker is restarted. However, the management console indicates that the broker's listening on the configured port number while it is not the case (netstat shows another UDP port number). The reason is that (as seen in the following block) the UdpTransport constructor does not assign "this.port" from remoteLocation but only reads the address and leaves "this.port" to be zero. Subsequently, Java API picks any available port number when it is creating the DatagraSocket. The solution is to add this line: "this.port = remoteLocation.getPort();" to the following constructor as seen in the accompanying patch.
> public UdpTransport(OpenWireFormat wireFormat, URI remoteLocation) throws UnknownHostException, IOException {
> this(wireFormat);
> this.targetAddress = createAddress(remoteLocation);
> description = remoteLocation.toString() + "@";
> }
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-3359) UDP Transport connector listens on a
random port number
Posted by "Amir Malekpour (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13091760#comment-13091760 ]
Amir Malekpour commented on AMQ-3359:
-------------------------------------
Well, I have to disagree with you on this. I even resorted to "println" to make sure the method that is called IS the one
I've mentioned above. (Even if it wasn't this is clearly a bug in that method to ignore the provided port number, so ignoring the bug on the basis that its' not called does not seem sound to me, though as I sad it is called).
Now as for a case that proves the existence of the bug, just run the broker with UDP transport and use netstat to check if the broker is actually listening on the specified port. You'll see that it isn't. Honestly, if this is not a convincing case I don't know what is.
> UDP Transport connector listens on a random port number
> -------------------------------------------------------
>
> Key: AMQ-3359
> URL: https://issues.apache.org/jira/browse/AMQ-3359
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.4.0, 5.4.1, 5.4.2, 5.5.0
> Reporter: Amir Malekpour
> Labels: broker, port, transport, udp
> Attachments: AMQ-3359.patch
>
> Original Estimate: 5m
> Remaining Estimate: 5m
>
> The broker listens on a random UDP port number instead of the one configure in the URI. The port number changes each time the broker is restarted. However, the management console indicates that the broker's listening on the configured port number while it is not the case (netstat shows another UDP port number). The reason is that (as seen in the following block) the UdpTransport constructor does not assign "this.port" from remoteLocation but only reads the address and leaves "this.port" to be zero. Subsequently, Java API picks any available port number when it is creating the DatagraSocket. The solution is to add this line: "this.port = remoteLocation.getPort();" to the following constructor as seen in the accompanying patch.
> public UdpTransport(OpenWireFormat wireFormat, URI remoteLocation) throws UnknownHostException, IOException {
> this(wireFormat);
> this.targetAddress = createAddress(remoteLocation);
> description = remoteLocation.toString() + "@";
> }
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (AMQ-3359) UDP Transport connector listens on a
random port number
Posted by "Amir Malekpour (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Amir Malekpour reopened AMQ-3359:
---------------------------------
Well, I have to disagree with you on this. I even resorted to "println" to make sure the method that is called IS the one I've mentioned above. (Even if it wasn't this is clearly a bug in that method to ignore the provided port number, so ignoring the bug on the basis that its' not called does not seem sound to me, though as I sad it is called).
Now as for a case that proves the existence of the bug, just run the broker with UDP transport and use netstat to check if the broker is actually listening on the specified port. You'll see that it isn't. Honestly, if this is not a convincing case I don't know what is.
> UDP Transport connector listens on a random port number
> -------------------------------------------------------
>
> Key: AMQ-3359
> URL: https://issues.apache.org/jira/browse/AMQ-3359
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.4.0, 5.4.1, 5.4.2, 5.5.0
> Reporter: Amir Malekpour
> Labels: broker, port, transport, udp
> Attachments: AMQ-3359.patch
>
> Original Estimate: 5m
> Remaining Estimate: 5m
>
> The broker listens on a random UDP port number instead of the one configure in the URI. The port number changes each time the broker is restarted. However, the management console indicates that the broker's listening on the configured port number while it is not the case (netstat shows another UDP port number). The reason is that (as seen in the following block) the UdpTransport constructor does not assign "this.port" from remoteLocation but only reads the address and leaves "this.port" to be zero. Subsequently, Java API picks any available port number when it is creating the DatagraSocket. The solution is to add this line: "this.port = remoteLocation.getPort();" to the following constructor as seen in the accompanying patch.
> public UdpTransport(OpenWireFormat wireFormat, URI remoteLocation) throws UnknownHostException, IOException {
> this(wireFormat);
> this.targetAddress = createAddress(remoteLocation);
> description = remoteLocation.toString() + "@";
> }
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-3359) UDP Transport connector listens on a
random port number
Posted by "Timothy Bish (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13045673#comment-13045673 ]
Timothy Bish commented on AMQ-3359:
-----------------------------------
Looks like you might need to update the unit tests to handle this fix otherwise you get a bunch of port in use exceptions. Should also add some tests to ensure that the port value specified is used.
> UDP Transport connector listens on a random port number
> -------------------------------------------------------
>
> Key: AMQ-3359
> URL: https://issues.apache.org/jira/browse/AMQ-3359
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.4.0, 5.4.1, 5.4.2, 5.5.0
> Reporter: Amir Malekpour
> Labels: broker, port, transport, udp
> Attachments: AMQ-3359.patch
>
> Original Estimate: 5m
> Remaining Estimate: 5m
>
> The broker listens on a random UDP port number instead of the one configure in the URI. The port number changes each time the broker is restarted. However, the management console indicates that the broker's listening on the configured port number while it is not the case (netstat shows another UDP port number). The reason is that (as seen in the following block) the UdpTransport constructor does not assign "this.port" from remoteLocation but only reads the address and leaves "this.port" to be zero. Subsequently, Java API picks any available port number when it is creating the DatagraSocket. The solution is to add this line: "this.port = remoteLocation.getPort();" to the following constructor as seen in the accompanying patch.
> public UdpTransport(OpenWireFormat wireFormat, URI remoteLocation) throws UnknownHostException, IOException {
> this(wireFormat);
> this.targetAddress = createAddress(remoteLocation);
> description = remoteLocation.toString() + "@";
> }
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQ-3359) UDP Transport connector listens on a
random port number
Posted by "Amir Malekpour (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Amir Malekpour updated AMQ-3359:
--------------------------------
Description:
The broker listens on a random UDP port number instead of the one configure in the URI. The port number changes each time the broker is restarted. However, the management console indicates that the broker's listening on the configured port number while it is not the case (netstat shows another UDP port number). The reason is that (as seen in the following block) the UdpTransport constructor does not assign "this.port" from remoteLocation but only reads the address and leaves "this.port" to be zero. Subsequently, Java API picks any available port number when it is creating the DatagraSocket. The solution is to add this line: "this.port = remoteLocation.getPort();" to the following constructor as seen in the accompanying patch.
public UdpTransport(OpenWireFormat wireFormat, URI remoteLocation) throws UnknownHostException, IOException {
this(wireFormat);
this.targetAddress = createAddress(remoteLocation);
description = remoteLocation.toString() + "@";
}
was:
The broker listens on a random UDP port number instead of the one configure in the URI. The port number changes each time the broker is restarted. However, the management console indicates that the broker's listening on the configured port number but netstat shows another UDP port number. The reason is that as seen in the
following block, the UdpTransport constructor does not read this.port from remoreLocation and only reads its address and leaves the this.port to be zero. The solution is to add this line: this.port = remoteLocation.getPort();
public UdpTransport(OpenWireFormat wireFormat, URI remoteLocation) throws UnknownHostException, IOException {
this(wireFormat);
this.targetAddress = createAddress(remoteLocation);
description = remoteLocation.toString() + "@";
}
> UDP Transport connector listens on a random port number
> -------------------------------------------------------
>
> Key: AMQ-3359
> URL: https://issues.apache.org/jira/browse/AMQ-3359
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.4.0, 5.4.1, 5.4.2, 5.5.0
> Reporter: Amir Malekpour
> Labels: broker, port, transport, udp
> Attachments: AMQ-3359.patch
>
> Original Estimate: 5m
> Remaining Estimate: 5m
>
> The broker listens on a random UDP port number instead of the one configure in the URI. The port number changes each time the broker is restarted. However, the management console indicates that the broker's listening on the configured port number while it is not the case (netstat shows another UDP port number). The reason is that (as seen in the following block) the UdpTransport constructor does not assign "this.port" from remoteLocation but only reads the address and leaves "this.port" to be zero. Subsequently, Java API picks any available port number when it is creating the DatagraSocket. The solution is to add this line: "this.port = remoteLocation.getPort();" to the following constructor as seen in the accompanying patch.
> public UdpTransport(OpenWireFormat wireFormat, URI remoteLocation) throws UnknownHostException, IOException {
> this(wireFormat);
> this.targetAddress = createAddress(remoteLocation);
> description = remoteLocation.toString() + "@";
> }
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira