BusinessConnect 7.X Gateway Server doesn't start

BusinessConnect 7.X Gateway Server doesn't start

book

Article ID: KB0079312

calendar_today

Updated On:

Products Versions
TIBCO BusinessConnect 7.0.0 and above

Description

When starting up the BusinessConnect Gateway Server, the following exception is thrown, and the Gateway Server shuts down:

[2019-02-20 19:24:25,460(INFO )]GatewayServer Ack Idle bootstrap ...
[2019-02-20 19:24:25,558(ERROR)]GatewayServer Failed to ack idle bootstrap.
com.tibco.ax.gs.runtime.GatewayRuntimeException: Ack idle bootstrap failed.
    at com.tibco.ax.gs.runtime.GatewayServer.ackIdleBootStrap(GatewayServer.java:343)
    at com.tibco.ax.gs.runtime.GatewayServer.init(GatewayServer.java:126)
    at com.tibco.ax.gs.runtime.GatewayServer.<init>(GatewayServer.java:73)
    at com.tibco.ax.gs.runtime.GatewayServer.Startup(GatewayServer.java:676)
Caused by: java.lang.NullPointerException
    at com.tibco.ax.gs.runtime.impl.GSBootstrapUtil.sendDmzMshRequest(GSBootstrapUtil.java:348)
    at com.tibco.ax.gs.runtime.impl.GSBootstrapUtil.sendDmzMshRequest(GSBootstrapUtil.java:344)
    at com.tibco.ax.gs.runtime.GatewayServer.ackIdleBootStrap(GatewayServer.java:341)
    ... 3 more

The Gateway Server has previously started successfully.

Issue/Introduction

The BusinessConnect 7.X Gateway Server doesn't start, even with the Interior Server running.

Environment

all platforms

Resolution

Starting with BC 7.0, the Gateway to Interior Server communication is done with EMS queues rather than RV.   When the GS needs to communicate with the IS, there are three queues uses:

<Installation Prefix>.<Installation Name>.DMZMSH-MESSAGE
This queue is used to initiate inbound requests to the IS from the GS

<Installation Prefix>.<Installation Name>.DMZMSH-MESSAGE-REPLY
This queue is used to send the reply to the inbound requests from the IS tothe GS
 
<dynamic queue> . 
This queue is dynamically created and cannot be seen by the EMS administrator.  It is created by the IS when the DMZMSH-MESSAGE-REPLY is sent, and is used to receive the reply from the GS when the DMZMSH-MESSAGE-REPLY is sent by the IS.

If the IS or GS goes down unexpectedly, messages can be left in these queues that will interfere with the initial DMZMSH-MESSAGE or the that is sent to the IS.

To resolve the issue, shut down the GS and IS, and check the queues mentioned for pending messages in the DMZMSH-MESSAGE and DMZMSH-MESSAGE-REPLY queues.  If there are pending messages, purge these queues, and restart the IS and GS in that order.  This should resolve the issue.