Qpid
  1. Qpid
  2. QPID-4062

Java system tests sometimes fail due to JMX port already initialised

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 0.16
    • Fix Version/s: 0.17
    • Component/s: Java Tests
    • Labels:
      None

      Description

      I'm often seeing errors such as this:

      java.rmi.server.ExportException: Port already in use: 18999; nested exception is: 
      	java.net.BindException: Address already in use
      	at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:310)
      	at sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:218)
      	at sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:393)
      	at sun.rmi.transport.LiveRef.exportObject(LiveRef.java:129)
      	at sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:190)
      	at sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:92)
      	at sun.rmi.registry.RegistryImpl.<init>(RegistryImpl.java:68)
      	at java.rmi.registry.LocateRegistry.createRegistry(LocateRegistry.java:222)
      	at org.apache.qpid.server.management.JMXManagedObjectRegistry.start(JMXManagedObjectRegistry.java:215)
      	at org.apache.qpid.server.registry.ApplicationRegistry.initialise(ApplicationRegistry.java:311)
      	at org.apache.qpid.server.registry.ApplicationRegistry.initialise(ApplicationRegistry.java:202)
      	at org.apache.qpid.server.Broker.startupImpl(Broker.java:123)
      	at org.apache.qpid.server.Broker.startup(Broker.java:97)
      	at org.apache.qpid.test.utils.QpidBrokerTestCase.startBroker(QpidBrokerTestCase.java:394)
      	at org.apache.qpid.test.utils.QpidBrokerTestCase.startBroker(QpidBrokerTestCase.java:354)
      	at org.apache.qpid.test.utils.QpidBrokerTestCase.startBroker(QpidBrokerTestCase.java:349)
      	at org.apache.qpid.test.utils.QpidBrokerTestCase.setUp(QpidBrokerTestCase.java:295)
      	at org.apache.qpid.management.jmx.MessageStatisticsTestCase.setUp(MessageStatisticsTestCase.java:61)
      	at org.apache.qpid.test.utils.QpidBrokerTestCase.runBare(QpidBrokerTestCase.java:237)
      	at org.apache.qpid.test.utils.QpidTestCase.run(QpidTestCase.java:139)
      Caused by: java.net.BindException: Address already in use
      	at java.net.PlainSocketImpl.socketBind(Native Method)
      	at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:365)
      	at java.net.ServerSocket.bind(ServerSocket.java:319)
      	at java.net.ServerSocket.<init>(ServerSocket.java:185)
      	at java.net.ServerSocket.<init>(ServerSocket.java:97)
      	at sun.rmi.transport.proxy.RMIDirectSocketFactory.createServerSocket(RMIDirectSocketFactory.java:27)
      	at sun.rmi.transport.proxy.RMIMasterSocketFactory.createServerSocket(RMIMasterSocketFactory.java:333)
      	at sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:649)
      	at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:299)
      
      

        Activity

        Hide
        Philip Harvey added a comment -

        attached patch

        Show
        Philip Harvey added a comment - attached patch
        Hide
        Philip Harvey added a comment -

        Rob - I've attached a patch. Please review and commit if you're happy.

        Show
        Philip Harvey added a comment - Rob - I've attached a patch. Please review and commit if you're happy.
        Hide
        Philip Harvey added a comment -

        In case anyone is wondering why this hack is really necessary, I've attached a test program illustrating that closing the socket used by the RMI Registry is inherently asynchronous (unlike closing a plain old ServerSocket, if my tests are to be believed).

        In the attached jar, run class com.philharveyonline.SocketPlay, and notice that it sometimes complains that the port is not free after the socket has seemingly been closed.

        The program is managing the socket using LocateRegistry.createRegistry / UnicastRemoteObject.unexportObject. If you edit the code to use SocketHelper instead of RmiSocketHelper, the socket is managed using straightforward new ServerSocket / socket.close calls. In this case, it never complains about the port not being freed up.

        Show
        Philip Harvey added a comment - In case anyone is wondering why this hack is really necessary, I've attached a test program illustrating that closing the socket used by the RMI Registry is inherently asynchronous (unlike closing a plain old ServerSocket, if my tests are to be believed). In the attached jar, run class com.philharveyonline.SocketPlay, and notice that it sometimes complains that the port is not free after the socket has seemingly been closed. The program is managing the socket using LocateRegistry.createRegistry / UnicastRemoteObject.unexportObject. If you edit the code to use SocketHelper instead of RmiSocketHelper, the socket is managed using straightforward new ServerSocket / socket.close calls. In this case, it never complains about the port not being freed up.
        Hide
        Philip Harvey added a comment -

        attached test program - see previous comment

        Show
        Philip Harvey added a comment - attached test program - see previous comment

          People

          • Assignee:
            Rob Godfrey
            Reporter:
            Philip Harvey
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development