PDS lock source file(.w, .p not .i) when changing branch or sources (EGit) - Forum - OpenEdge Development - Progress Community

PDS lock source file(.w, .p not .i) when changing branch or sources (EGit)

 Forum

PDS lock source file(.w, .p not .i) when changing branch or sources (EGit)

This question is answered

Our situation:

We have planned to move from the classic editor(with shared resource) to PDS a while ago.
Because PDS works the best with local resources we will use EGit. So you can work easily with local sources.
Also it have benefits for upgrading our integration(nowadays not ok because of shared resources) to integrate new features with Continuous integration through Git and a build server.

Problem:

In the mean time I have done much of tests and then when we blend everything together we have a problem in PDS.
There is a problem that keeps files locked for a certain time if we switch from branch to branch.
I think it's have something to do with that new sources are added to the project when switching from branch.
.i files are not affected

Tests with procedure files:
1) Maybe something with the Progress builder but if i disable them the problem remains:
Hmmm...


Still failing :(

If I use the tool handle.exe from windows for checking who is locking the files it's the javaw process PDS like expected.

javaw.exe          pid: 8536   type: File           ED4: C:\.......\custom.p

2) Still thinking it have something to do with the build
Under the Workspace there are also preferences for the build Progress OpenEdge - Editor - Build
I will remove the p in the property "Compilable file extensions"

Yes the problem disappear we have an anchor point


But like you can expect this is not what I want. It's lightly needed that I can compile some help would be appreciated!


Kind regards

Kevin Hermans

Verified Answer
All Replies
  • Hi

    I had similar, maybe same problem in last September. I was consulting another company in a project where we went from appbuilder to Dev Studio, CVS to GIT and started using Jenkins. At first I was proposing, they should use eGit, but soon it was clear that is is impossible, we had the same issue, as you are describing when we changed branch, some files were not changed, files and amount of files was random. We did a lot of testing and found out, that for projects, that have low amount of source codes, it is not a problem, but our main project had ~19000 source codes and usually about 200-300 we not switched out  when we changed branch. At first we thought that it is some Disk IO thing, since disk was 100% during every branch switch but then we found this bugs.eclipse.org/.../show_bug.cgi. Seems like it is a known bug and we switched to using TortoiseGit (https://tortoisegit.org/) and the problems disappeared.

  • Thank you for the quick response the bug you mentioned was in EGit 3.3  we are in 4.1 maybe it's solved.

    But to be sure I did the test with 15000 sources of a project and adapted 600 files with a "replace all" then I committed those in an new branch.
    I begin swiching between two branches and as long as I let out the .p and .w in the "Compilable file extensions" it was no problem no locks, but from the moment I put them back in the compilable extensions which OpenEdge have to build the problem returned.
    Also when I disable "Build automatically".

    Then I have taken a look to the tool they also used in your bug link.
    I can see that only the files who are changed are affected  this I can see in the logs.
    The duration of when all the locks are finished is 50 seconds to 1minute and 30 seconds for these changes.

    If I tell to the developers that they have to wait for 2 minutes after each switch of branch the problem will not occur but I can't guaranty that they will do that...

    Every file is locked by the same thread hopefully this is mean full for someone

    #16 C:\Users\keh\git\h2020\src\objn\app1berekentmp.p by thread:Code Model build Job on Fri Feb 17 13:39:02 CET 2017
    	at java.io.FileInputStream.<init>(FileInputStream.java:147)
    	at com.openedge.pdt.core.ast.InputSource$FileSource.getReader(InputSource.java:216)
    	at com.openedge.pdt.core.ast.ASTManager.createAST(ASTManager.java:349)
    	at com.openedge.pdt.core.ast.ASTManager.createAST(ASTManager.java:242)
    	at com.openedge.pdt.project.util.OEProjectUtil.getCompilationUnit(OEProjectUtil.java:667)
    	at com.openedge.pdt.project.util.OEProjectUtil.getCompilationUnit(OEProjectUtil.java:639)
    	at com.openedge.pdt.project.codeinfo.reader.CodeReaderUtil.createCodeContainerInfo(CodeReaderUtil.java:252)
    	at com.openedge.pdt.project.codeinfo.reader.CodeReaderUtil.createCodeContainerInfo(CodeReaderUtil.java:176)
    	at com.openedge.pdt.project.codeinfo.reader.CodeReaderUtil.getCodeContainer(CodeReaderUtil.java:365)
    	at com.openedge.pdt.project.codeinfo.reader.CodeReaderUtil.getResourceCodeContainer(CodeReaderUtil.java:292)
    	at com.openedge.pdt.project.codeinfo.CodeModelAddRemoveManager.addFileToLibrary(CodeModelAddRemoveManager.java:72)
    	at com.openedge.pdt.project.codeinfo.CodeModelBuildManager.excuteResourceOperation(CodeModelBuildManager.java:322)
    	at com.openedge.pdt.project.codeinfo.CodeModelBuildManager.excuteOperation(CodeModelBuildManager.java:249)
    	at com.openedge.pdt.project.codeinfo.CodeModelBuildManager.access$9(CodeModelBuildManager.java:246)
    	at com.openedge.pdt.project.codeinfo.CodeModelBuildManager$1$1.run(CodeModelBuildManager.java:113)
    	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
    	at com.openedge.pdt.project.codeinfo.CodeModelBuildManager$1.run(CodeModelBuildManager.java:109)

  • I noticed this problem only for files which have a compile error. As a workaround you can open the problematic source files in an editor or reopen the file. This will eliminate the lock.

  • PDSOE also locks the assemblies, once with the javaw process and once for each AVM withing PDSOE.

    eGit (including 4.1) does not handle this nicely, see also https://bugs.eclipse.org/bugs/show_bug.cgi?id=374294

    Example

    handle TelerikCommon.dll

    Handle v3.51
    Copyright (C) 1997-2013 Mark Russinovich
    Sysinternals - www.sysinternals.com

    javaw.exe          pid: 23492  type: File          1DE8: ...\assemblies\Telerik\TelerikCommon.dll
    prowin.exe         pid: 29000  type: File           AAC: ....\assemblies\Telerik\TelerikCommon.dll

  • There is a work-around for this issue (files that has compilation errors getting locked by PDSOE) - run the Java Garbage collector.

    I posted the details in another thread - https://community.progress.com/products/beta-eap/oe117-esap/f/232/p/29875/100275#

    Regards

    Suresh

  • As not everybody has access to the ESAP forum, can you please share the details about the workaround here in full details?

    Thanks!

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • Many thanks to Suresh Inavolu the details for people who doesn't have access to the ESAP forum like Mike mentioned.

    Posted by on 27 Feb 2017 6:56

    We are able to reproduce this issue (as steps mentioned above) - I will log a bug for this. As you mentioned, this happens only when the abl code has errors.

    There is a work-around for now (until it is fixed in the product) - run the Java garbage collector (GC).

    Enable 'Show heap status' from the preferences (Window > Preferences), in General section select 'Show heap status'

    This show the memory used by PDSOE in the bottom right.

    Click on the trash button - this will manually run the GC (and closes the files that are no longer accessible).

    Now you can use the Git tool (as PDSOE don't lock the file anymore).

    I am using ESAP4 build of PDSOE 11.7 (but this should work for 11.6.3 or before also) - please confirm if it is working for you.

    Thanks for identifying - we will try to fix ASAP.