How does the 304 Modification Checks work in 7.x?

[bonigv]

I am facing serious degradation of performance on requests that hits server and receives back a 304 status code.   Firebug clearly shows that there is no fetch from the server for requests I know are already cached on the client side.  However the initial check with the server takes a long time to return. 

Requests that took 5ms to return in AS5 takes 120ms and more on AS7.  Could you please help me understand what happens under the hoods to determine a 304 status code?

[bonigv]

My war is around 2GB in size.  It is that big because of the way GWT compiles for multiple languages and browsers.  The static content is burhied deep within the war.  It seems that ETag based evaluation of 304 check degrades considerably with te size of WAR.  Does Jboss keep a tree in memory or does it use the disk checksum to decide on Etag modifications?  Seems like server is doing something very time consuming to evaluate content expiry check.  And it seems the algorithm is not optimized for large WARs

[heiko.braun]

GWT apps tend to be big after compilation, but 2GB is way too big. Try tweaking the GWT compiler settings to create obfuscated javascript code. See http://www.gwtproject.org/doc/latest/FAQ_DebuggingAndCompiling.html for further details