asadmin deploy of GFv3.1.1_b11 is much slower than that of Gfv3.1

glassfishrobot commented 13 years ago

I noticed that asadmin deploy My.ear is much slower of 3.1.1_b11 compared to 3.1. Actually it needs two minutes to deploy, while it had been just a few seconds.

I checked the log and found that virtually the complete time is spent between these two lines:

...whatever it does within that two minutes...

Environment

Win7 Pro SP1 64 Bit de_DE

Affected Versions

[3.1.1_dev]

glassfishrobot commented 6 years ago

Issue Imported From: https://github.com/javaee/glassfish/issues/17031
Original Issue Raised By:@glassfishrobot
Original Issue Assigned To: @tjquinno
Original Issue Closed By:@glassfishrobot

glassfishrobot commented 13 years ago

@glassfishrobot Commented @tjquinno said: I am copying here my response to your forum post/mailing list question.

It's not clear whether the extra work required to track such stale files is causing the longer deployment time. Can you confirm that this is the same app you already sent me privately?

On Windows a file left open cannot be renamed or deleted. This can interfere with subsequent deployments or executions of an app with the same name.

Normally this is not a big issue, because GlassFish will overwrite-in-place a "stale" file left over from an earlier deployment with the file from the new deployment. But if a file was present in the earlier app but not in a subsequent one, and if GlassFish cannot delete it, then that could be a problem because the file would remain in the directory GlassFish uses to expand the deployed archive.

To prevent this, on Windows GlassFish does some extra processing on the expansion directory. It keeps track of such "stale" files - leftover files from previous deployments of the app that do not appear in the current deployment of the app - and it ignores these stale files.

The message you see is GlassFish informing you that, for some reason, it could not delete that directory (either because some file remains in that directory or the directory itself is currently open by some process) and that it is ignoring that directory because it does not appear in the newly-deployed app.

Note that this can happen - in fact this problem first appeared - if you deploy a completely different app with the same name (using --name appName on the deploy command, for example) as an earlier app. In your case, it looks as if you are reusing the app name Foo.

glassfishrobot commented 13 years ago

@glassfishrobot Commented @honghzzhang said: assign to tim to follow up on this

glassfishrobot commented 13 years ago

@glassfishrobot Commented mkarg said: Tim,

we meanwhile fixed some of our own bugs in the EAR. The problem was noticed since 3.1.1_b11 while we sent our EAR to you when we had used 3.1. So I don't know whether the changed EAR or the changed GF release is causing it. If you like I can send you an updated EAR.

BTW, I do not clearly understand why the same file is used again. If the problem on windows is a commonly known one, there would be a simple trick to solve that: Create a temporary file name using Windows' API functions. That names are guaranteed to be unique, so the "cannot-kill-nor-overwrite" would not play a role.

Regards Markus

glassfishrobot commented 13 years ago

@glassfishrobot Commented @tjquinno said: Markus,

Please send me the EAR that triggers this issue. Thanks.

If the QUIPSY_war directory (the expanded directory for what I assume is a WAR module in your app) exists both in the original expanded directory and the one resulting from the redeployment, then the stale file manager should be detecting that the directory is created during the redeployment also and NOT flag it as stale. Having your latest app will help us see what's going on.

As for reusing the directory, one reason is that part of the published interface of GlassFish is that users can create or touch the file ".reload" in the application's directory to cause the app to be redeployed. For many releases this location has been documented as $

{domainDir}

/applications/$

{appName}

. So we cannot simply change that without changing past behavior and potentially breaking users' existing scripts and procedures.

glassfishrobot commented 13 years ago

@glassfishrobot Commented @tjquinno said: Another thought on the warning about QUIPSY_war...

It's possible that part of deployment is looking for that directory before it expands into it. Because it is left over from the previous deployment, we see the warning, but then deployment goes ahead and uses it anyway (as it should) which renders it no longer stale at that point.

So this might be a warning that can be ignored. Maybe we can relax the wording of the warning a bit or make a minor adjustment to deployment's check for the directory. I'll look into it at some point.

glassfishrobot commented 13 years ago

@glassfishrobot Commented mkarg said: Undeployed, rebootet machine, deployed again. Still several minutes waiting time between the following lines:

[#|2011-07-15T11:33:26.761+0200|WARNING|glassfish3.1.1|javax.enterprise.system.tools.deployment.org.glassfish.deployment.common|_ThreadID=21;_ThreadName=Thread-2;|DPL8019: The run-as principal QUIPSY_User was assigned by the deployment system based on the specified role. Please consider defining an explicit run-as principal in the sun-specific deployment descriptor.|#]

In fact, I started asadmin deploy command 11:31:00 on that machine, and the machine was rather bored that time (my local workstation; no CPU or HDD activity). So it is absolutely unclear why it took nearly three minutes between those lines. As that machine needs only less than one minute to pack that EAR, it cannot need three minutes to unpack it.

Maybe you like me to switch some logging levels to better see what happens in that time?

glassfishrobot commented 12 years ago

@glassfishrobot Commented @tjquinno said: This is a duplicate of 17094.

glassfishrobot commented 13 years ago

@glassfishrobot Commented Issue-Links: duplicates GLASSFISH-17094

glassfishrobot commented 7 years ago

@glassfishrobot Commented This issue was imported from java.net JIRA GLASSFISH-17031

glassfishrobot commented 13 years ago

@glassfishrobot Commented Reported by mkarg

glassfishrobot commented 12 years ago

@glassfishrobot Commented Marked as duplicate on Monday, June 11th 2012, 4:58:21 pm

eclipse-ee4j / glassfish

asadmin deploy of GFv3.1.1_b11 is much slower than that of Gfv3.1 #17031

Environment

Affected Versions