Most of my gateways I access through a VPN, and when I disconnect from the VPN and try to close a designer it always takes a very long time to close.
I press the close button 100 times and a minute later the "are you sure" confirmation shows up, I press "Exit" (don't save). Then I wait 5-10mins for it to actually close down. I would kill it from task manager but it's impossible to tell what process ties to what designer, and I don't want to accidentally close another designer instead.
Why is this? Is it contacting the gateway and waiting for a response? Can it not do that and only do it if you click "Save and Exit"?
Thread dumps during this process would be helpful; could you set up a script that writes the result of system.util.threadDump to a file and start it running infinitely (maybe with a cap ) in the script console or something, then attempt a shutdown?
This one delayed for a little bit but not as long as usual. I ran the script and tried to close within a second or two of running it.
for future me when I test it again
from java.lang.System import nanoTime as nt
import time
t1 = nt()
for i in xrange(450):
t2 = nt()
a = system.util.threadDump()
with open(r"c:\t\D log {}.log".format(i), 'w') as f:
f.write('{}\r\n'.format( (t2-t1) / 1000000000.0 ) )
f.write(a)
time.sleep(0.2)
Hmm, it seems that I may have been caught in a temporal anomaly that affected my sense of time, as the logs i've captured since have all shown it closes within about 30s. I added time to the top in seconds since start of execution Close Logs E.zip (463.9 KB)
Hmm. I haven't looked at every thread dump, but most of the later ones show a blocking network call on the EDT () from Perspective, trying to tell the gateway to close out the Designer's active session/tab.
Moving that work off the EDT would probably help shutdown performance (since you won't be "locked" while the designer spins trying to connect to something it will never be able to reach in this scenario) but could have tricky ramifications in more regular scenarios - you don't want the designer to close faster than the message is emitted, thus leaving "ghost" sessions around on the gateway until the idle timeout kicks in. We already have enough session persistence problems with the designer ...
) in the script console or something, then attempt a shutdown?
) from Perspective, trying to tell the gateway to close out the Designer's active session/tab.
...