[support-swapna]

Copied from feedback by Jozef Boer:

I receive the following error from MyEclipse when deploying to Tomcat. After that it asks me if I want to close to workbench. If I don’t agree to this I can continue, but I’ll occasionally see the same error message and the Servers view will be frozen. A restart fixes the problem until I need to replace my jar files again.

An internal error occurred during: “Updating status for ATSC Development Tomcat…”.
jzentry == 0,
jzfile = 549914128,
total = 607,
name = F:\Workspaces\Git\JB\fitch\fitch\WebRoot\WEB-INF\lib\thirdparty-spring-web-4.3.8.RELEASE.jar,
i = 1,
message = ZIP_Read: error reading zip file

I’ve noticed that it’s always spring-web that’s causing the issue. spring-web is also the only jar file visible under my deployments in the Servers view. Is there something special about this library that it affects my Tomcat deployment?

[support-tony]

Jozef,

Can you give us more details, please?

We assume you’re using the latest release of MyEclipse 2017 CI (CI 8) and that you’re still on Windows 10 but just need to confirm this.

Also, please let us know how you’re deploying the project and attach screenshots of the error and the Server’s view showing the jar file under your deployed project. Lastly, please clear the error log, reproduce the error and attach the error log (it can be exported from the Error Log view to a text file). If the problem is not reproducible consistently, then just attach the error log after you see the error.

Sorry for the inconvenience.

[Jozef_jb]

Just had another one occur. Again in this case the jar file was never written to, only read to compare to another file.

I’ve attached the error log.

Environment:
– Running MyEclipse 2017 Stable 1.0
– Windows 10 w/ the Creators Update
– Project is a Web Project with Web App Libraries added to the build path which point to the same project
– Project is deployed to a custom Apache Tomcat 7.x server (NOT the embedded MyEclipse server)
– Prior to checking/copying/replacing jar files in WEB-INF/lib the Tomcat instance is stopped

There’s also something I don’t understand…

Screenshot of Servers view: https://i.imgur.com/wEO80Kx.png

Why is there a thirdparty-spring-web-4.3.8.RELEASE.jar there? That file exists in WEB-INF/lib (we automatically prefix filenames of thirdparty libraries with “thirdparty-“). But why that jar? Why not all? Or none? Is there something special about this jar?

• This reply was modified 7 years, 3 months ago by Jozef_jb.

Attachments:

You must be logged in to view attached files.

[Brian Fernandes]

Jozef,

Thank you for answering, in advance, a number of questions I would have asked 🙂

First, spring-web-4.3.8 is a web fragment – this is why it is treated, and behaves, differently.

The other errors we see in your log seem to indicate that these JAR files are getting corrupted at some point in time – the errors are from JDT not being able to successfully read them.

I’m assuming all the errors were when you initiate the deployment? Can you tell me what deployment action you are using?

Your log file contains errors for atsc-asset-core-3.6.8-SNAPSHOT.jar – is there any chance that this file is actually corrupt at times? If this is a file that’s downloaded from a Maven repository, sometimes the local repository could contain a corrupt file.

Another question is the version of Java with which the above file was created. Quite a bit unlikely that there could be an incompatibility here, but I have seen it happen when the Eclipse instance runs a different version of Java.

Finally, could you send us your .project file and all the files from your project’s .settings folder? That will give us some better insight into your actual project set up. Not sure if your project is a Maven project, but if it is, sharing the pom.xml file will help too.

Hope to figure this out with your details.

[Jozef_jb]

> First, spring-web-4.3.8 is a web fragment – this is why it is treated, and behaves, differently.

Is there a way to disable this “web fragment” functionality? I don’t see what functionality this provides… and I don’t think we use it…

All we want is for MyEclipse to copy the contents of the “WebRoot” folder to our Tomcat webapps folder with the same project name. We don’t need all this extra overhead…

> I’m assuming all the errors were when you initiate the deployment?

No. The problem occurs when we forcibly overwrite jar files.

Our project structure:

/
/WebRoot
/WebRoot/WEB-INF
/WebRoot/WEB-INF/lib
/pom.xml

We have libraries in “WEB-INF/lib” and a pom.xml file in the project. However, the project is not a Maven project. We have “Web App Libraries” on the build path, which makes MyEclipse use jar files from the “WEB-INF/lib” folder.

We have written a script so that, when we run “Maven clean” on the pom.xml, it will 1) delete the contents of “WEB-INF/lib” and 2) copy the jar files of all included dependencies to the “WEB-INF/lib” folder. This allows us to get the latest versions of libraries.

> Your log file contains errors for atsc-asset-core-3.6.8-SNAPSHOT.jar – is there any chance that this file is actually corrupt at times?

There is an underlying problem here. The root cause is that MyEclipse has a tendency to lock jar files in the “WEB-INF/lib” folder… but not always.

Sometimes our script would work and overwrite the jar files. Sometimes our script would fail because the file was locked by the MyEclipse (javaw) process.

If we encountered this lock, retrying would not fix it… MyEclipse would keep the lock forever, and it would often persist even after restarting MyEclipse.

When this lock problem occurred we have tried to delete the file through MyEclipse. But then MyEclipse complains that it can’t delete the file. It doesn’t seem to understand that the only reason the file can’t be deleted is because MyEclipse itself is holding an exclusive lock on it.

Our “solution” to this problem is to run a 3rd party tool called LockHunter to forcibly remove the lock on “WEB-INF/lib” and any files in that folder before overwriting them. Not the most ideal, but the lesser of two evils as we can avoid having to restart MyEclipse in “most” cases.

Technically it’s possible for the file to be seen as corrupted during the copy process. However, we can confirm that the copy process is always successful and if the file is ever corrupt, it’s only for a few seconds at most.

> Another question is the version of Java with which the above file was created.

All in-house jar files are generated with Java 1.8.0_77. I don’t know what thirdparty jars have been generated with, but those tend not to change.

> Hope to figure this out with your details.

It sounds simple to me, but maybe I’m being too naive.

For starters, (My)Eclipse should not be locking jar files in “WEB-INF/lib”.

The file is not corrupted when I get that error, I have confirmed this with 3rd party tools. It may have been overwritten with a slightly different copy at some point in the past.

I don’t know the specifics of the (My)Eclipse codebase, but shouldn’t it be possible to abort and read the file again? Currently, it never restores itself and we’re forced to restart MyEclipse for seemingly no reason, as code completion etc. still seems to work.

[Brian Fernandes]

Jozef,

I’m afraid there isn’t a way to remove the web fragment tech right now, though I don’t think that’s the cause of your problems.

From your notes, it appears that the crux of your issues remains the originally reported bug – the fact that the JDT is locking JAR files, sometimes, resulting in non-deterministic behavior when an attempt is made to update these files.

As we discussed earlier, the problem lies in the Eclipse JDT core, a bug which the JDT team intends to fix only in the next major release of Eclipse. Yes, it does sound pretty straightforward to simply re-read the JAR, but knowing how deep in the IDE this is coming from, that’s much easier said than done.

I’ve been monitoring the bug, and unfortunately the fixes already presented aren’t 100% fixes, though reports indicate that it does mitigate the situation. A possibility would be for us to create either a replacement plugin or a patch which would apply that same fix to the version of Eclipse you are running and hope that it either fixes the issue entirely or at least lowers the frequency of occurrence. Would this work for your team, for now?

[Jozef_jb]

If it doesn’t take up too much of your time, a fix would be much appreciated, even if it’s a workaround/patch.

[Brian Fernandes]

Jozef,

We tried to replicate that problem locally so that we could test the patch locally too, but failed after dozens of attempts on Windows. I will still work towards getting you the fix next week, however, would love to be able to reproduce locally as well.

Just so we try with the same type of project, can you share with us your .project file and all the files in the .settings folder? This will help us ensure we have all the same builders and classpath containers as you do.

As far as when the error occurs, would this be the right sequence?
1) Attempt to run mvn clean
2) Command fails to delete files
3) Run LockHunter to release lock
4) Run mvn clean again.
Do you only see the error if you had to use LockHunter? Or could it occur during #2 as well – if the mvn clean command ran successfully the first time (with no prior use of LH during that session either)

Finally, any reason why your project is not a Maven project (not using the MyEclipse Maven facet)? This would add a Maven classpath container into your project containing references to libraries from your local Maven repository, and of course, these would be deployed to WEB-INF/lib and be on your project’s classpath. If you update the pom.xml to specify new versions of libraries, the classpath container will be updated accordingly. Not sure if this works with your use case of getting the latest version of the JARs you mentioned (are they being rebuilt while keeping the same versions, for instance?). Given the nature of this problem, having the JARs in the classpath container instead of physically in the lib folder might change the locking characteristics, which is why I ask.

Thanks!

[Jozef_jb]

The error only occurs when the lock has been removed by LockHunter. Otherwise the Maven Clean task stalls.

Our project is not a Maven project for two reasons:

1. The contents of WEB-INF/lib are sacred; that’s what Tomcat runs as. It doesn’t make sense to compile with different jars.
2. We’ve had performance issues with Maven in the past where (My)Eclipse decides to run the Maven Builder on all projects. When I’m working I don’t want to build projects unrelated to what I’m working on, but I can’t always close them because I may need to be able to deploy them quickly at any time.
3. Shared Maven libraries, which meant that whenever we ran Maven Clean on an unrelated project it would also update the jars for other projects, spitting out errors because those projects haven’t been updated.

Attached is our .project, .settings and .classpath files.

Attachments:

You must be logged in to view attached files.

[support-tony]

Jozef,

Thanks for the files. We’ll investigate further and get back to you.

[Jozef_jb]

Any progress? I’ve come across this issue again.

I’m trying to update our local Maven repositories remotely. Currently we’ve configured Maven to query our in-house repository for every snapshot library that is touched. But it’s better if our build server updates the repository automatically.

Unfortunately, with “Maven Dependencies” in the build path, the problem occurs again: jar files in the Maven repository are locked, preventing them from being overwritten by other processes.

The upstream issue doesn’t seem to have much activity after October of last year…

[Brian Fernandes]

Jozef,

To be honest I was hoping there would have been better progress reported over at Eclipse. With the files provided and dozens of local attempts, were were unable to reproduce the lock locally – making it impossible for us to work on a problem as intricate and deep as this.

I could create the patch referenced in the bug (the earlier one), which I believe we had discussed earlier in this thread – I cannot find a record of having sent this to you though and I do not recall if someone from tech sent it across? Did you receive it?

I’m not too hopeful about this (the patch) because as you can see in the bug, users have reported failures even after applying the patch, and the most recent fix was a bust too 🙁

[candacegarcia]

I was looking for it. Thanks you

[Author]

Posts