[JLivermore]

That <meta> tag is not necessary to avoid IE crashing with the Drawing/Charts module loaded, as you can see from the Showcase or any sample project. Something else is wrong. Of course, you may not want to bother investigating now that you have a working setup.

I see that, thanks for pointing that out.

The DEBUG statements in the logs you showed (such as those in the category/log level "DEBUG ISCKeyedObjectPool") are not temporary log statements - they are permanent diagnostic logs available in the system. Again, your log4j settings are allowing these messages through, and that's not the default we ship with the product.

Thanks for setting me straight, I didn't go back far enough in our history to see the original setup, now that it's been restored, our logs are pretty small.

[Isomorphic]

That <meta> tag is not necessary to avoid IE crashing with the Drawing/Charts module loaded, as you can see from the Showcase or any sample project. Something else is wrong. Of course, you may not want to bother investigating now that you have a working setup.

The DEBUG statements in the logs you showed (such as those in the category/log level "DEBUG ISCKeyedObjectPool") are not temporary log statements - they are permanent diagnostic logs available in the system. Again, your log4j settings are allowing these messages through, and that's not the default we ship with the product.

[JLivermore]

There were no JS errors.

Our log4j.isc.comfig.xml file is intact and unmodified. Those DEBUG statements was from the build that was created for us while Isomorphic was trouble shooting a bug in your server code that caused our server to freeze and become unresponsive.

I had asked for the DEBUG statements to be removed, but there was no response afterwards. I believe this DEBUG settings are on the branch where the fix was applied, but the DEBUG statements were not un-done. You may want to check the DEBUG settings on the branch where this version lives: SmartClient Version: v9.1p_2014-10-20/PowerEdition Deployment (built 2014-10-20)

[JLivermore]

This issue was an IE Document mode issue. We enabled

<inherits name="com.smartgwt.Drawing"/>
<inherits name="com.smartgwt.Charts"/>

in our Main.gwt.xml file. It appears that IE was defaulting to mode 7. This was the cause of our app hanging on the client. I added

<meta http-equiv="X-UA-Compatible" content="IE=Edge">

to our bootstrap JSP page and this fixes the issue. With that added statement, IE will default to the max available Document mode given the IE version at hand.

[Isomorphic]

So, as we expected, you're not using the default log settings that come with the product - you may be missing log4j.isc.config.xml, or you may have just misplaced it.

Also *still* have not heard about JS errors. Just a reminder again that this is the very first thing to check for and report.

What resources are you seeing hanging mid-load? Please show a screenshot for whatever tool is showing you these hung or failing requests, with whatever details it provides.

[JLivermore]

Note that this whole server log thing is a bit of an aside - the suggestions re: JavaScript errors and fixing GWT/caching are much more likely to be where the problem is.

Looking at the DevConsole/Network Downloads, I can see the *.Main.nocache.js 200 GET and the response downloaded OK. What is interesting is the next several 200 GETs are hung with no response?

[JLivermore]

Something sounds like something is odd with your log system. Try posting just a starting snippet of the server log.

Here is the last bit of log with IE that hangs:

=== 2015-08-10 08:19:20,554 [c-10] DEBUG ISCKeyedObjectPool - Borrowing object for 'field'
=== 2015-08-10 08:19:20,554 [c-10] DEBUG ISCKeyedObjectPool - Borrowing object for 'OperationBinding'
=== 2015-08-10 08:19:20,554 [c-10] DEBUG ISCKeyedObjectPool - Borrowing object for 'binding'
=== 2015-08-10 08:19:20,554 [c-10] DEBUG ISCKeyedObjectPool - Borrowing object for 'ServerObject'
=== 2015-08-10 08:19:20,554 [c-10] DEBUG ISCKeyedObjectPool - Borrowing object for 'serverObject'
=== 2015-08-10 08:19:20,554 [c-10] DEBUG DataSourceLoader - For DataSource 'time_frame', got instanceId 383
=== 2015-08-10 08:19:20,554 [c-10] INFO  Compression - /tzw/com.anstca.tz.Main/sc/DataSourceLoader: 90326 -> 5548 bytes
=== 2015-08-10 08:19:20,616 [ec-8] INFO  RequestContext - URL: '/tzw/com.anstca.tz.Main/sc/skins/anstca/load_skin.js', User-Agent: 'Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/7.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; CMDTDFJS; F9J)': MSIE with Accept-Encoding header, ready for compressed JS
=== 2015-08-10 08:19:20,616 [ec-8] INFO  Download - done streaming: C:/Program Files/Apache/Tomcat 8.0/webapps/tzw/com.anstca.tz.Main/sc/skins/anstca/load_skin.js
=== 2015-08-10 08:19:20,616 [ec-8] INFO  Compression - /tzw/com.anstca.tz.Main/sc/skins/anstca/load_skin.js: 22868 -> 5048 bytes
=== 2015-08-10 08:19:20,632 [ec-1] INFO  RequestContext - URL: '/tzw/com.anstca.tz.Main/sc/skins/anstca/skin_styles_ie7.css', User-Agent: 'Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/7.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; CMDTDFJS; F9J)': MSIE with Accept-Encoding header, ready for compressed JS
=== 2015-08-10 08:19:20,632 [ec-1] INFO  Download - done streaming: C:/Program Files/Apache/Tomcat 8.0/webapps/tzw/com.anstca.tz.Main/sc/skins/anstca/skin_styles_ie7.css
=== 2015-08-10 08:19:20,632 [ec-1] INFO  Compression - /tzw/com.anstca.tz.Main/sc/skins/anstca/skin_styles_ie7.css: 620 -> 302 bytes
=== 2015-08-10 08:19:20,632 [ec-5] INFO  RequestContext - URL: '/tzw/com.anstca.tz.Main/sc/skins/anstca/skin_styles.css', User-Agent: 'Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/7.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; CMDTDFJS; F9J)': MSIE with Accept-Encoding header, ready for compressed JS
=== 2015-08-10 08:19:20,632 [ec-5] INFO  Download - done streaming: C:/Program Files/Apache/Tomcat 8.0/webapps/tzw/com.anstca.tz.Main/sc/skins/anstca/skin_styles.css
=== 2015-08-10 08:19:20,632 [ec-5] INFO  Compression - /tzw/com.anstca.tz.Main/sc/skins/anstca/skin_styles.css: 54602 -> 8092 bytes
=== 2015-08-10 08:19:20,694 [ec-4] INFO  RequestContext - URL: '/tzw/com.anstca.tz.Main/clear.cache.gif', User-Agent: 'Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/7.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; CMDTDFJS; F9J)': MSIE with Accept-Encoding header, ready for compressed JS
=== 2015-08-10 08:19:20,710 [ec-4] INFO  Download - done streaming: C:/Program Files/Apache/Tomcat 8.0/webapps/tzw/com.anstca.tz.Main/clear.cache.gif

[JLivermore]

Hi JLivermore,

perhaps it is not SmartGWT related at all. Did you test with emptied browser cache? Perhaps IE cached com.anstca.tz.Main/com.anstca.tz.Main.nocache.js and the old version links to a big cache-permutation that does no longer exist.
With empty cache, do you see a HTTP 200 for the .nocache.js and one *.cache.js (using IE F12 tools)?

Best regards
Blama

Yes, in the DevTools for IE, I do see a 200 GET for com.anstca.tz.Main.nocache.js
That is where the client begins to hang in terms of resource requests and downloads. I see 4 more requests made with no responses...after *.Main.nocache.js is downloaded.

[Isomorphic]

Something sounds like something is odd with your log system. Try posting just a starting snippet of the server log.

Note that this whole server log thing is a bit of an aside - the suggestions re: JavaScript errors and fixing GWT/caching are much more likely to be where the problem is.

[JLivermore]

We also never got an answer on the nature of the hang:

the CPU is idle.

[JLivermore]

It doesn't matter whether this is a production or development deployment - the SmartGWT Developer Console should still be available, and the browser's built-in tools are definitely always available.

Again on the logs, the default log levels we ship with the product would not product such large logs. Whenever we ask for logs, we always just want logs with the default settings unless we specifically request something else.

If you're running with settings that produce such large logs, you should definitely restore the default settings that ship with the framework, for multiple reasons: performance, easier to read logs, easier to send to other people.

No changes made to log4j.isc.comfig.xml
I removed all of our debug statements, the rest are the framework's which is prefixed with '==='.

[Isomorphic]

We also never got an answer on the nature of the hang:

100% CPU or totally idle?

[Isomorphic]

It doesn't matter whether this is a production or development deployment - the SmartGWT Developer Console should still be available, and the browser's built-in tools are definitely always available.

Again on the logs, the default log levels we ship with the product would not product such large logs. Whenever we ask for logs, we always just want logs with the default settings unless we specifically request something else.

If you're running with settings that produce such large logs, you should definitely restore the default settings that ship with the framework, for multiple reasons: performance, easier to read logs, easier to send to other people.

[JLivermore]

Another idea:
If it is not cache-related you could try to deploy under a different path and sub-path. Perhaps IE does not like the dots in the path?

Best regards
Blama

I'm going to have a look at this, thank you for the suggestion.

Results - this had no affect. i changed the path to something very simply and still had the same behavior. Thanks for the idea though.

[Blama]

Another idea:
If it is not cache-related you could try to deploy under a different path and sub-path. Perhaps IE does not like the dots in the path?

Best regards
Blama