- This topic has 4 replies, 2 voices, and was last updated 17 years, 5 months ago by Riyad Kalla.
-
AuthorPosts
-
gkelleyMemberI’ve noticed that MyEclipse seems to be building EARs and WARs in the location where they are to be deployed. Lately, this strategy has been causing problems for myself and a couple other people here at work when the EARs/WARs are quite large (more than a couple megabytes). The problem seems to be occurring because MyEclipse begins creating the archive, and before it can finish writing all the contents of the archive, the application servers seem to be picking up on the presence of a new file and then try to deploy it. However, if MyEclipse hasn’t finished writing all the contents of the archive by the time the application server tries to deploy it, the server will often times throw errors stating something along the lines of “invalid zip file”, “unable to open file”, “can’t find META-INF/application.xml”, etc.
Has anyone else out there encountered this problem? At this point I’d just like to get some feedback on this scenario…I’m not yet trying to say if and what should be done about it. Thanks in advance!
Gregg
Riyad KallaMemberGregg,
The only workaround for this is to increase the scan-time for your app server so it doesn’t check too quickly. Unfortunately this problem will exist no matter what we do (for example, build the JAR, then copy it into place… you can imagine a JAR big enough that it takes a few moments to copy, so you would still run into the same problem).Each app server has it’s own settings for increasing the time-out time, please double-check your docs to see how your app server handles it.
gkelleyMemberThanks Riyad. The two things you mention–increasing the appserver’s scan-time and building the archive in a temp location–are the workarounds my coworkers and I have been using. I am going to do some research to determine if it’s feasible for the appserver to not attempt the deployment until the archive is “finished” or “closed”.
gkelleyMemberWell I’ve done a little research and I’m beginning to think this issue may get down to the OS layer. The fundamental question is: how can the JRE know if a file is “done” being written to? I don’t know much about filesystem implementations, but I could see this question having a complex answer, possibly even different answers depending on the OS and the filesystem. Maybe some day I’ll research more about that, but I don’t have time right now, so I started looking for the short-term solution. Here’s what I’ve found for the two appservers we use most often:
OC4J: it seems as if once autodeployment of an EAR has failed, OC4J won’t attempt to re-autodeploy that EAR in the future, even if one manually deletes and recreates the EAR in the autodeploy directory. As Riyad mentioned, one can set the “polling” interval for OC4J. For more info, see http://download.oracle.com/docs/cd/B31017_01/web.1013/b28950/threadpool.htm
JBoss: even if an autodeployment fails, JBoss seems to continue to attempt to autodeploy the archive in the future. So, once the creation of the archive is complete, JBoss will eventually try to autodeploy it again. One can also customize the the “polling” interval for JBoss. For more info, see http://wiki.jboss.org/wiki/Wiki.jsp?page=ConfiguringTheDeploymentScannerInConfjbossSystem.xml
Riyad KallaMembergkelley,
This was a really helpful follow up, thank you for taking the time to post it. I’ve even added it to our FAQ with full credits:
http://www.myeclipseide.com/PNphpBB2-viewtopic-t-18101-sid-c1deff5ae35c7815adf83d88a545dd22.htmland
http://www.myeclipseide.com/PNphpBB2-viewtopic-t-18102-sid-c1deff5ae35c7815adf83d88a545dd22.html
-
AuthorPosts