EnsLib.JavaGateway.Service - Gateway Server failure timeout

Recently I started moving some of our JDBC Gateway configurations over to using the Microsoft JDBC Gateway driver instead of using the jTDS open source driver. I have noticed since then that those Objects that are using Microsoft JDBC Driver are throwing a lot more errors than the jTDS driver ever did, which I can understand however I am puzzled that I keep running into an issue with the Java Gateway Service within the Interoperability engine.

Every so often I will start seeing "Gateway Server failure timeout on 127.0.0.1:55550" followed by "Gateway Server did not respond to PING request..." Even though the Heartbeat Failure Action is set to Restart, it never truly shuts down and restarts like it should. 

I thought the issue might be with Garbage Collection and handling of memory so that is why I have the DisableExplicitGC, AggressiveOpts, and CMSClassUnloadingEnabled JVM arguments set within the Java Gateway.

The only difference is that within those that are using the Microsoft JDBC Driver and this CPD.JavaGateway vs the others that are using jTDS Driver and other Java Gateways is that the Class Path for the CPD.JavaGateway above is not defined as WRC said I didn't need to define it if the Class Path was set within the JDBC Gateway connections. Should I define the class path in the java gateway? If I do doesn't that defeat the purpose of possibly using different drivers per JDBC configuration?

The other Objects (Business Services, Business Processes, and Business Objects) that use this particular Java Gateway and Microsoft JDBC Driver will eventually throw a "ERROR #5023: Remote Gateway Error: java.lang.OutOfMemoryError: Compressed class space"

I thought it might be something with port scanning but however I do not see any "Gateway Server failure" errors on any of the other Java Gateways within the Interoperability engine. 

To get everything running again, I have to shutdown all the Objects that might use that Java Gateway, Stop/Start the Java Gateway in question, and then restart all the objects that were previously shutdown.