Service Virtualization

Expand all | Collapse all

VSE Connection To Webshpere MQ Instance

Jump to Best Answer
  • 1.  VSE Connection To Webshpere MQ Instance

    Posted 06-08-2016 01:33 PM


    One of our users has recorded some WebSphere MQ traffic.  When they deploy the .VSM file out to the VSE and start the service, it will immediately fail with the following error ::

     

    ========================================================
    | Exception: 
    ============================================================================
    | Message:     Error opening queue manager QM_TEST, Completion Code 2 (MQCC_FAILED), Reason Code 2059 (MQRC_Q_MGR_NOT_AVAILABLE)
    ----------------------------------------------------------------------------
    | Trapped Exception: MQJE001: Completion Code '2', Reason '2059'.
    | Trapped Message:   com.ibm.mq.MQException: MQJE001: Completion Code '2', Reason '2059'.
    ----------------------------------------------------------------------------
    STACK TRACE
    com.ibm.mq.MQException: MQJE001: Completion Code '2', Reason '2059'.
    ...
    Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2059;AMQ9204: Connection to host 'win1552218(1414)' rejected. [1=com.ibm.mq.jmqi.JmqiException[CC=2;RC=2059;AMQ9205: The host name supplied is not valid. [3=win1552218,4=TCP]],3=win1552218(1414),5=RemoteTCPConnection.resolveHostname]
      at com.ibm.mq.jmqi.remote.internal.RemoteFAP.jmqiConnect(RemoteFAP.java:2072)
      at com.ibm.mq.jmqi.remote.internal.RemoteFAP.jmqiConnect(RemoteFAP.java:1286)
      at com.ibm.mq.MQSESSION.MQCONNX_j(MQSESSION.java:923)
      at com.ibm.mq.MQManagedConnectionJ11.<init>(MQManagedConnectionJ11.java:230)
      ... 43 more
    Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2059;AMQ9205: The host name supplied is not valid. [3=win1552218,4=TCP]
      at com.ibm.mq.jmqi.remote.internal.RemoteTCPConnection.resolveHostname(RemoteTCPConnection.java:400)
      at com.ibm.mq.jmqi.remote.internal.RemoteTCPConnection.parseConnectionName(RemoteTCPConnection.java:288)
      at com.ibm.mq.jmqi.remote.internal.RemoteTCPConnection.protocolConnect(RemoteTCPConnection.java:942)
      at com.ibm.mq.jmqi.remote.internal.system.RemoteConnection.connect(RemoteConnection.java:1162)
      at com.ibm.mq.jmqi.remote.internal.system.RemoteConnectionPool.getConnection(RemoteConnectionPool.java:353)
      at com.ibm.mq.jmqi.remote.internal.RemoteFAP.jmqiConnect(RemoteFAP.java:1660)
      ... 46 more
    ============================================================================
    

     

     

    All components are on individual devices.  Meaning, DevTest Workstation is on its own server, DevTest VSE is on its own server, and the WebSphere instance is on its own server.

     

    We have tried defining the MQ asset with fully-qualified names yet that doesn't have any effect. 
    Is there something else we have to do in order for the VSE to successfully reach out to the MQ instance?



  • 2.  Re: VSE Connection To Webshpere MQ Instance

    Broadcom Employee
    Posted 06-08-2016 01:40 PM

    Is the user able to connect to the Websphere MQ instance from his workstation?

    If so, it might be that the DT VSE server is not able to resolve the win1552218 host to the Websphere server IP.

     

    Check if you can open a connection from the DT VSE server to the Websphere server using telnet on port 1414.

    You can try using the IP address of Websphere server instead of the hostname & see if that works.



  • 3.  Re: VSE Connection To Webshpere MQ Instance

    Posted 06-08-2016 01:57 PM

    CORRECTION ::

    The user has gone back and rebuilt the entire DevTest project and used FQDN for the assets and now the behavior is different. 

    It appears that the VSE at least knows who to connect to for the MQ instance but the connection is timing out.

    Any suggestions?

    ============================================================================
    | Exception:
    ============================================================================
    | Message:    Error opening queue manager QM_TEST, Completion Code 2 (MQCC_FAILED), Reason Code 2059 (MQRC_Q_MGR_NOT_AVAILABLE)
    ----------------------------------------------------------------------------
    | Trapped Exception: MQJE001: Completion Code '2', Reason '2059'.
    | Trapped Message:  com.ibm.mq.MQException: MQJE001: Completion Code '2', Reason '2059'.
    ----------------------------------------------------------------------------
    STACK TRACE
    com.ibm.mq.MQException: MQJE001: Completion Code '2', Reason '2059
    ....
      at com.itko.lisa.coordinator.Instance.run(Instance.java:204)
    Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2059;AMQ9204: Connection to host 'win1552218.northamerica.cerner.net(1414)' rejected. [1=com.ibm.mq.jmqi.JmqiException[CC=2;RC=2059;AMQ9213: A communications error for  occurred. [1=java.net.ConnectException[Connection timed out],3=win1552218.northamerica.cerner.net]],3=win1552218.northamerica.cerner.net(1414),5=RemoteTCPConnection.connnectUsingLocalAddress]
      at com.ibm.mq.jmqi.remote.internal.RemoteFAP.jmqiConnect(RemoteFAP.java:2072)
      at com.ibm.mq.jmqi.remote.internal.RemoteFAP.jmqiConnect(RemoteFAP.java:1286)
      at com.ibm.mq.MQSESSION.MQCONNX_j(MQSESSION.java:923)
      at com.ibm.mq.MQManagedConnectionJ11.<init>(MQManagedConnectionJ11.java:230)
      ... 43 more
    Caused by: com.ibm.mq.jmqi.JmqiException: CC=2;RC=2059;AMQ9213: A communications error for  occurred. [1=java.net.ConnectException[Connection timed out],3=win1552218.northamerica.cerner.net]
      at com.ibm.mq.jmqi.remote.internal.RemoteTCPConnection.connnectUsingLocalAddress(RemoteTCPConnection.java:675)
      at com.ibm.mq.jmqi.remote.internal.RemoteTCPConnection.protocolConnect(RemoteTCPConnection.java:1003)
      at com.ibm.mq.jmqi.remote.internal.system.RemoteConnection.connect(RemoteConnection.java:1162)
      at com.ibm.mq.jmqi.remote.internal.system.RemoteConnectionPool.getConnection(RemoteConnectionPool.java:353)
      at com.ibm.mq.jmqi.remote.internal.RemoteFAP.jmqiConnect(RemoteFAP.java:1660)
      ... 46 more
    Caused by: java.net.ConnectException: Connection timed out
      at java.net.PlainSocketImpl.socketConnect(Native Method)
      at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
      at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
      at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
      at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
      at java.net.Socket.connect(Socket.java:589)
      at java.net.Socket.connect(Socket.java:538)
      at com.ibm.mq.jmqi.remote.internal.RemoteTCPConnection$5.run(RemoteTCPConnection.java:662)
      at java.security.AccessController.doPrivileged(Native Method)
      at com.ibm.mq.jmqi.remote.internal.RemoteTCPConnection.connnectUsingLocalAddress(RemoteTCPConnection.java:655)
      ... 50 more
    


  • 4.  Re: VSE Connection To Webshpere MQ Instance

    Posted 06-08-2016 02:13 PM

    It still sounds like a network-level issue.  Have you tried Prem's suggestion of using the telnet tool to see if a socket connection to win1552218.northamerica.cerner.net on port 1414 is possible from the machine you are running this test from?



  • 5.  Re: VSE Connection To Webshpere MQ Instance

    Posted 06-08-2016 02:18 PM

    Apologies, I got caught up in another issue.  We will try out Prem's suggestion momentarily and update this thread with the results.



  • 6.  Re: VSE Connection To Webshpere MQ Instance

    Posted 06-08-2016 03:27 PM

    Prem_Bairoliya and Kevin.Bowman -
    I tried the recommendation of using Telnet to connect from VSE to the server the MQ instance is on and after about 60 seconds, I get a connection timeout.



  • 7.  Re: VSE Connection To Webshpere MQ Instance
    Best Answer

    Broadcom Employee
    Posted 06-08-2016 03:32 PM

    This looks to be a network related issue. Please contact your network team to get this ironed out.

     

    Connection timeouts (assuming a local network and several client machines) typically result from

    a) some kind of firewall on the way that simply eats the packets without telling the sender things like "No Route to host"

    b) packet loss due to wrong network configuration or line overload