[jira] [Issue Comment Edited] (AMQ-3359) UDP Transport connector listens on a random port number

["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