Application Client Traffic Overhead in GlassFish v3

I have an EAR application with Application Client module.

When this EAR file is deployed on GlassFish v2 and Application Client module is present in the cache, amount of the traffic between the client machine and the server during Application Client launch is approx. 0.7KB.

But when I deploy this application on GlassFish v3 and launch Application Client module second or third time (so that it is already present in the cache), amount of the traffic between client machine and the server during Application Client launch is 10MB.

What can be wrong?

UPD 1

Even if I create a simple EAR project with Application Client component that just outputs "Hello World" and deploy it on GlassFish v3, it is still 5-6MB every time Application Client is launched from the cache.

UPD 2

Trying to dig deeper into the problem.

When I launch the application from cache in the GlassFish v3, I get the following exception in the GlassFish v3 log for each library in my Application Client:

java.io.IOException: An established connection was aborted by the software in your host machine

for example:

SEVERE: Adapter[/___JWSappclient/___system] s1as/glassfish/modules/webservices-osgi.jar
java.io.IOException: An established connection was aborted by the software in your host machine
    at sun.nio.ch.SocketDispatcher.write0(Native Method)
    at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:33)
    at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:100)

I have an assumption, that traffic overhead can be related. There is some information on the internet about this problem. But apparently there is no official explanation or a way how to fix it.

Here is an interesting thread related to this problem, which may shed some light on it.

Here is how Tim (more tjquinn) commented the situation:

The "established connection aborted" messages are ones we've seen but seem, as you said, not to affect the launch. I think - but have not verified - that Java Web Start starts a download of a JAR and then discovers that the cached copy is up-to-date and so aborts the transfer. This should not happen, but I have not discovered exactly what is causing it to know if it's a Java Web Star开发者_如何学运维t problem or a Grizzly problem (that's the transport layer basically in GlassFish) or a GlassFish problem itself.

UPD 3 There is an interesting discussion on "Old Nabble" about similar issue. We also had failing web services symptoms after launching the Application Client.

UPD 4 Oleksiy Stashok from Grizzly forums (the thread mentioned in UPD 3) suggested posting the question on Java Web Start forum. And here is the link to the thread on Java Web Start forums.