Hi  @Dan Pahnke 
The "Red Fire Button"  is a synonym I used over the years with my various teams for an action/decision
that should not be taken by a single person but follows (at least) the 4-eyes-principle.

Inspired by an endless number of Airforce fighting movies from Hollywood and
the old but still incredible song from The Dubliners.
And its best cover version

#1)  check that ALL code Dbs are part of your Mirror. 
There is a fair chance that not all code you use is in a single code DB but is mapped to other DBs.
I'm not talking about implicitly mapped pieces like all System and %* Utilities.
#2) If  you use code mapping It is highly important that Package mapping AND routine mapping go hand in hand
#3) Whatever Mirror is synchronizing is based on Global Journal. So also all code DBs require Journalling.
    Since every routine or class whether deployed or not is stored in some global.

But my personal preference is not to apply Mirror to code DBs.
Mainly to control the point in time when a Change/Update happens.  
I'm a fan of the Red Fire Button and like to control the moment  of essential changes
 

Typically a %ResultSet is an object. It is destroyed as soon as you de-reference it.
This could be a ba killing the referencing variable or by assigning a different value.
there is no need for a %Close or an object destructor.  this happens implicitely.

set rs= ##class(%ResultSet).%New()
. . . . ; work it 
kill rs
; or 
set rs=""

What you see could be explained best by "model mismatch"
Java Gateway connection stays as long as the connecting process exists.
While CSP.REST services a  request and stops.
To avoid repeated connection times you may run some background process as worker jobs that open Java Gateway
and get its requests from your CSP.Rest.
As you have Ensemble already, you might run your Java Gateway as a Business Service connecting OnInit() an stay connected.
This is of course all asynchronous processing which affects your response time.

If you revert it and a Java process is scanning request using Native API for Java I wouldn't expect more attractive timing. 

 

some ideas from the hip:

  • classic SOAP service
  • running a background job over ECP
  • having a listening job that triggers whatever you need
  •  using WebSocket communications

They all run over TCP as there is nothing else between separated servers.
At the bottom line, you rely on some code expecting a request.
"Native API" for various languages, or Studio, or CSP do the same over Super Server Port (1972) 
the quality is different, not the principle.