Bug 1002580
Summary: | Received "FileSystem is close" while business central was building a project | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Retired] JBoss BRMS Platform 6 | Reporter: | Ivo Bek <ibek> | ||||||||
Component: | Business Central | Assignee: | Alexandre Porcelli <porcelli> | ||||||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Ivo Bek <ibek> | ||||||||
Severity: | unspecified | Docs Contact: | |||||||||
Priority: | high | ||||||||||
Version: | 6.0.0 | CC: | etirelli, ibek, jlocker, rrajasek, vigoyal | ||||||||
Target Milestone: | ER5 | Keywords: | Reopened | ||||||||
Target Release: | 6.0.0 | ||||||||||
Hardware: | Unspecified | ||||||||||
OS: | Unspecified | ||||||||||
Whiteboard: | |||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||
Doc Text: |
Summary: While building a project via the Project Authoring GUI or via a REST API call, Business Central is unable to rebuild a project. Instead it shows the error message: File System is Close and no further work on the Project can be done.
Cause:
Consequence:
Fix:
Result:
|
Story Points: | --- | ||||||||
Clone Of: | Environment: |
Fedora 19 x86_64
OpenJdk 1.7.0_45
Firefox 24
|
|||||||||
Last Closed: | 2014-08-06 20:17:15 UTC | Type: | Bug | ||||||||
Regression: | --- | Mount Type: | --- | ||||||||
Documentation: | --- | CRM: | |||||||||
Verified Versions: | Category: | --- | |||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||
Embargoed: | |||||||||||
Attachments: |
|
Description
Ivo Bek
2013-08-29 13:22:38 UTC
Created attachment 792129 [details]
Part of server log
This issue happens only when you start bpms with standalone.xml .... running bpms with standalone-full.xml works well. (In reply to Ivo Bek from comment #2) > This issue happens only when you start bpms with standalone.xml .... running > bpms with standalone-full.xml works well. Works better but not well enough. "FileSystem is close.." encountered with standalone-full.xml too. To be able to "rebuild" a project, all instances must be aborted, deployment unit undeployed and folder with the project archive removed from eap/bin/repository. Otherwise the project build doesn't work because of the "FileSystem is close" issue. This approach is just my way how to deal with the issue. I don't recommend to implement it this way ;) Needs more info on how to reproduce this... is it running in cluster? what are the project config that you're trying to build? After several attempts... I wasn't able to reproduce it. Here is how I'm running it via rest: curl -i -u admin:admin -H "Content-Type:application/json" -X POST "http://127.0.0.1:8888/rest/repositories/uf-playground/projects/mortgages/maven/install" -d '{}' No it didn't run in cluster. It was a basic installation with EAP6. It's much more difficult to reproduce it now in ER3. Jirka told me that it happened sometime while he changed a project but we will let you know when we see it more often. The issue is back and for some reason it happens almost every time I install the project on my local machine. With Jirka Locker we checked the source codes and we don't understand why the exception is thrown there https://github.com/droolsjbpm/kie-commons/blob/master/kie-nio2-backport/kie-nio2-impls/kie-nio2-jgit/src/main/java/org/kie/commons/java/nio/fs/jgit/JGitFileSystem.java#L282 So instead to try to reproduce it, I would avoid to have such a exception because when we want to close fileSystem it's not a problem to have it already closed, is it? What do you think? Or if you think the exception is important there, why it should bother the user? Then the exception could be caught on the server side. IIRC this piece of code follows NIO2 semantics, but I'm fine to remove it (doesn't have any impact anyway). https://github.com/droolsjbpm/kie-commons/commit/d57c3c7f3 https://github.com/droolsjbpm/kie-commons/commit/652f719f1 Created attachment 812438 [details]
FileSystem is close response in BPMS 6.0.0.ER4
The GenericPortableException: "FileSystem is close" is still present in BPMS 6.0.0.ER4. Are you sure the commit is there?
Hi Alexandre, seems that after I remove a repository, the JGitFileSystem is closed and then if I create the repository once again (to be sure with the same name), the JGitFileSystem will remain closed, so the new build of a project won't be put to the new repository because there is nothing what would change isClosed property. When the isClosed property gets to true state, it will never change. https://github.com/droolsjbpm/uberfire/blob/master/uberfire-nio2-backport/uberfire-nio2-impls/uberfire-nio2-jgit/src/main/java/org/uberfire/java/nio/fs/jgit/JGitFileSystem.java Hi Ivo, I could see this, but I still coudln't reproduce the issue.. I created a junit test that creates, removes and then recreate a repository but still doesn't get this error (even without changing anything in the existing codebase, although I see that the situation that you described in your last comment is possible). Do you have a step by step that I could reproduce it? Using REST or GUI? Hi Alexandre, yep this bug is quite unpleasant. I hope I found the easiest way for you how to reproduce it with our own repository in GUI, so please follow these steps: 1) Install BPMS 6.0.0.ER4 with EAP 6.1.0 2) Add user admin with roles admin and analyst 3) Clone repository git://git.app.eng.bos.redhat.com/bpms-assets.git name it bpms-assets, and put it to the example org. unit 4) Open Project Authoring view, select example org. unit, bpms-assets repository and integration project. 5) Build & deploy the integration project in Project Editor 6) Go back to the list of repositories in Administration and delete the repository 7) Continue with Point #3 After you click on the button Build & deploy for the second time, you will see the Error dialog containing "Unable to complete your request. The following exception occurred: FileSystem is close.." Created attachment 815377 [details]
"FileSystem is close" screenshot
To make it clear, in the point #7 I mean to repeat the points #3, #4, and #5. My environment is Fedora 19 with OpenJDK 1.7. I'll record the process in video. Great, Thanks for the detailed steps now I could reproduce it! Fix is already pushed in UberFire repository master and 0.3.x branches: https://github.com/droolsjbpm/uberfire/commit/de1faff5f https://github.com/droolsjbpm/uberfire/commit/5531314fd That's great news, thank you, I recorded the video but it has 25MB so I couldn't upload it here. More fixes for this issue, pushed to Uberfire master and 0.3.x branch https://github.com/droolsjbpm/uberfire/commit/c3a3fb9a3 https://github.com/droolsjbpm/uberfire/commit/1a9be4ddd Verified in BPMS 6.0.0.ER5 |