UPDATE May 17, 2021:

This issue has bee resolved via a new property that has been introduced in:

BC 7.1.0 Hotfix 1
BC 7.2.0 Hotfix 1
BC 7.2.1 Hotfix 1

This article still applies to BC 7.0.0

See this section of the hotfix release announcement:
 

 Brute Force Attack - DMZMSH-REPLY-TIMEOUT Set the gateway server confirmation response timeout on the interior. This will prevent buildup of jobs that are hung waiting for response from gateway  when the gateway is under brute force attack or due to rogue clients that break  while the response is being transmitted. This value can be set in Tibco Administrator by navigating through :  Application Management > BusinessConnect > Configuration > Edit Application Configuration: >   Component Settings > Intercomponent Advanced > DMZ Interior Timeout (seconds) 

==========================================================================
When using BusinessConnect under a heavy load with a large number of inbound requests through the Gateway Server, the Interior Server stops processing messages.  This usually manifest itself with a large number of jobs in the engine.

When using the GetProcesses() microagent on the BC engine, there are a large number of these jobs in the engine:
 

Id	Name	TrackingId	CustomId	Status	StartTime	Duration	MainProcessName	CurrentActivityName	StarterName	SubProcessName
194579	Job-194579			Active	1.602E+12	5914316	Gateway/MSH/Inbound/From-DMZ/JMS Receiver.process	JMS Queue Requestor	Gateway/MSH/Inbound/From-DMZ/JMS Receiver.process	Gateway/MSH/Inbound/To-DMZ/Sync-Reply-to-DMZ.process

This is caused by inbound requests terminating in the Gateway Server before the Interior Server has a chance to respond to the inbound request.  The response gets "stuck" in the DMZMSH-REQUEST-REPLY queue, and the IS eventually hangs because these jobs never terminate, and the IS never times out.
 

all platforms

UPDATE May 17, 2021:

This issue has bee resolved via a new property that has been introduced in:

BC 7.1.0 Hotfix 1
BC 7.2.0 Hotfix 1
BC 7.2.1 Hotfix 1

See this section of the hotfix release announcement:
 

 Brute Force Attack - DMZMSH-REPLY-TIMEOUT Set the gateway server confirmation response timeout on the interior. This will prevent buildup of jobs that are hung waiting for response from gateway  when the gateway is under brute force attack or due to rogue clients that break  while the response is being transmitted. This value can be set in Tibco Administrator by navigating through :  Application Management > BusinessConnect > Configuration > Edit Application Configuration: >   Component Settings > Intercomponent Advanced > DMZ Interior Timeout (seconds) 

==========================================================================
To add IS timeouts to the deployed BC engine, follow these steps.  You must follow these steps after every redeployment of the BC engine:
 

1.  With an editor, edit this file.  Do not save a backup of this file in the same directory:

$TIBCO_HOME/tra/domain/<your_domain_name>/datafiles/BusinessConnect_root/Gateway/MSH/Inbound/To-DMZ/Sync-Reply-to-DMZ.process
 

2.  Look for this block of XML in the file:

   <pd:activity name="JMS Queue Requestor">
        <pd:type>com.tibco.plugin.jms.JMSQueueRequestReplyActivity</pd:type>
        <pd:resourceType>ae.activities.JMSQueueRequestReplyActivity</pd:resourceType>
        <pd:x>569</pd:x>
        <pd:y>383</pd:y>
        <config>
            <PermittedMessageType>Bytes</PermittedMessageType>
            <SessionAttributes>
                <transacted>false</transacted>
                <acknowledgeMode>1</acknowledgeMode>
                <maxSessions>1</maxSessions>
                <destination>%%gatewayProperties/server/prefix%%.%%gatewayProperties/server/installationName%%.DMZMSH-MESSAGE-REPLY</destination>
            </SessionAttributes>
            <ConfigurableHeaders>
                <JMSDeliveryMode>PERSISTENT</JMSDeliveryMode>
                <JMSExpiration>0</JMSExpiration>
                <JMSPriority>4</JMSPriority>
            </ConfigurableHeaders>
            <ConnectionReference>/Gateway/MSH/Inbound/From-DMZ/dmzmsh-msg-jms-config.sharedjmscon</ConnectionReference>
        </config>
        <pd:inputBindings>
            <ns:ActivityInput>
                <JMSCorrelationID>
                    <xsl:value-of select="$Start/root/dmz-closure"/>
                </JMSCorrelationID>
                <Body>
                    <xsl:value-of select="$serialize-sync-reply/ns7:SerializerDeserializerOutputRoot/Binary"/>
                </Body>
            </ns:ActivityInput>
        </pd:inputBindings>
    </pd:activity>

 

3.  Modify it by adding the highlighted lines as follows:

   <pd:activity name="JMS Queue Requestor">
        <pd:type>com.tibco.plugin.jms.JMSQueueRequestReplyActivity</pd:type>
        <pd:resourceType>ae.activities.JMSQueueRequestReplyActivity</pd:resourceType>
        <pd:x>569</pd:x>
        <pd:y>383</pd:y>
        <config>
            <PermittedMessageType>Bytes</PermittedMessageType>
            <SessionAttributes>
                <transacted>false</transacted>
                <acknowledgeMode>1</acknowledgeMode>
                <maxSessions>1</maxSessions>
                <destination>%%gatewayProperties/server/prefix%%.%%gatewayProperties/server/installationName%%.DMZMSH-MESSAGE-REPLY</destination>
            </SessionAttributes>
            <ConfigurableHeaders>
                <JMSDeliveryMode>PERSISTENT</JMSDeliveryMode>
                <JMSExpiration>0</JMSExpiration>
                <JMSPriority>4</JMSPriority>
            </ConfigurableHeaders>
            <ConnectionReference>/Gateway/MSH/Inbound/From-DMZ/dmzmsh-msg-jms-config.sharedjmscon</ConnectionReference>
        </config>
        <pd:inputBindings>
            <ns:ActivityInput>
                <JMSExpiration>
                <xsl:value-of select="180"/>
                </JMSExpiration>
                <JMSCorrelationID>
                    <xsl:value-of select="$Start/root/dmz-closure"/>
                </JMSCorrelationID>
                <requestTimeout>
                    <xsl:value-of select="180"/>
                </requestTimeout>
                <Body>
                    <xsl:value-of select="$serialize-sync-reply/ns7:SerializerDeserializerOutputRoot/Binary"/>
                </Body>
            </ns:ActivityInput>
        </pd:inputBindings>
    </pd:activity>
 

4. The “180” value above sets the timeout at 180 seconds (three minutes), which should be sufficient for most applications.   It can be shortened for higher load scenarios.
5. Save and restart the engine. 

When using BusinessConnect under a heavy load with a large number of inbound requests through the Gateway Server, the Interior Server stops processing messages.