This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Deployment of web module comes back with Deployment failed message even though the module has been successfully deployed. The deployment works with codebase before Aug9th. Checkin, http://j2eeserver.netbeans.org/servlets/ReadMsg?list=cvs&msgNo=1723 It appears that the modules list size used to determine success or failure is empty. Error Message: Trying to start application in target server completed successfully Deployment of application WebApplication1 completed successfully C:\Documents and Settings\Nitya Doraisamy\WebApplication1\nbproject\build-impl.xml:427: Deployment error: The module has not been deployed. See the server log for details. BUILD FAILED (total time: 2 minutes 41 seconds)
Created attachment 32785 [details] messahe when verbosity level set to debug
TM -> 5.5 Please use REGRESSION keyword rather than summary prefix.
*** Issue 82487 has been marked as a duplicate of this issue. ***
URGENT: I suggest you should revert the bad fix as this is blocking many many activities for us, while you investigate.
right now I am testing a hotfix, will commit it soon
make sure 8.2 and 9.0 are tested as we have seen different behaviour there.
Actually, my fix was not bad. This issue was caused on the plug-in/server side, specifically in the com.sun.enterprise.deployment.client.DeployAction class which introduces a race condition. Please note that the race condition cannot be fixed/workarounded completely outside the DeployAction class and therefor I am reassigning this issue to the appserver plug-in to take appropriate steps. The race condition is as follows: The DeployAction class implements the DeployableObject interface and is returned to the j2eeserver as a result of the deploy action. Once the j2eeserver obtains a reference to this object it registers a ProgressListener on it and starts listening to progress events. It seems that sometimes after the COMPLETED progess event arrives the DeployAction.getDeploymentStatus().isCompleted() method returns false instead of true. See attached debug log for more details. Please keep in mind that this is a VERY SERIOUS ISSUE, since due to the bad jsr88 design, the j2eeserver might register after the completed event arrived and the only chance to find out that the deployment completed is by checking the getDeploymentStatus().isCompleted() method. I put a workaround in the j2eeserver which uses the status information obtained by the ProgressListener instead of checking the getDeploymentStatus().isCompleted() method, this however does not solve the problem that could occur if the listener is registered to late. Changing the priority to P3 F. Checking in src/org/netbeans/modules/j2ee/deployment/impl/TargetServer.java; /cvs/j2eeserver/src/org/netbeans/modules/j2ee/deployment/impl/TargetServer.java,v <-- TargetServer.java new revision: 1.42.6.2.2.6; previous revision: 1.42.6.2.2.5 done
Created attachment 32845 [details] debug log
com.sun.enterprise.deployment.client.DeployAction is form the app server backend code. We cannot change AS 8.1, as 8.2 and as 9.0... I need to know if this bug will ever happen with these servers? Should I file the bug on AS 9.x for cleanup ?
I don't know in what version this race condition was introduced, but as long as the bug in the server exists this issue may happen again and it will be random. It should be definitelly fixed in the AS 9.x code.
But with the j2eeserver code before August 9, do you think the issue can happen as well?
Definitelly yes! BTW, the j2eeserver code before my fix was very shaky and the probability that some problem could occur was quite hight. The old code could lead to failure even if the bug in the AS itself didn't exist. The reason why this issue was discovered after my fix is that performance of the old code was worse and therefore there was bigger delay between the arrival of the event and checking the result of the getDeploymentStatus().isCompleted() method afterwards.
I filed https://glassfish.dev.java.net/issues/show_bug.cgi?id=996 on GlassFish product. Closing this one.