Bug 1002580 - Received "FileSystem is close" while business central was building a project
Received "FileSystem is close" while business central was building a project
Product: JBoss BRMS Platform 6
Classification: JBoss
Component: Business Central (Show other bugs)
Unspecified Unspecified
high Severity unspecified
: ER5
: 6.0.0
Assigned To: Alexandre Porcelli
Ivo Bek
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2013-08-29 09:22 EDT by Ivo Bek
Modified: 2014-08-06 16:17 EDT (History)
5 users (show)

See Also:
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:
Fedora 19 x86_64 OpenJdk 1.7.0_45 Firefox 24
Last Closed: 2014-08-06 16:17:15 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Part of server log (10.05 KB, text/x-log)
2013-08-30 07:36 EDT, Ivo Bek
no flags Details
FileSystem is close response in BPMS 6.0.0.ER4 (17.39 KB, text/x-log)
2013-10-15 07:25 EDT, Ivo Bek
no flags Details
"FileSystem is close" screenshot (16.03 KB, image/png)
2013-10-23 08:26 EDT, Ivo Bek
no flags Details

  None (edit)
Description Ivo Bek 2013-08-29 09:22:38 EDT
Description of problem:

It's not possible to install (build) a project. It's reproducible always via REST API and sometimes it happens in GUI.
From the server I receive following response:

    <error>FileSystem is close.</error>
    <stackTrace>org.guvnor.common.services.shared.exceptions.GenericPortableException: FileSystem is close.
	at org.guvnor.common.services.backend.exceptions.ExceptionUtilities.handleException(ExceptionUtilities.java:24)
	at org.guvnor.common.services.builder.BuildServiceImpl.buildAndDeploy(BuildServiceImpl.java:111)
	at org.guvnor.common.services.builder.BuildServiceImpl$Proxy$_$$_WeldClientProxy.buildAndDeploy(BuildServiceImpl$Proxy$_$$_WeldClientProxy.java)
	at org.kie.workbench.common.services.rest.ProjectResourceDispatcher.installProject(ProjectResourceDispatcher.java:273)
	at org.kie.workbench.common.services.rest.ProjectResourceDispatcher$Proxy$_$$_WeldClientProxy.installProject(ProjectResourceDispatcher$Proxy$_$$_WeldClientProxy.java)
	at org.kie.workbench.common.services.rest.KieSessionAsyncJobRequestObserver.onInstallProjectRequest(KieSessionAsyncJobRequestObserver.java:64)
	at org.kie.workbench.common.services.rest.KieSessionAsyncJobRequestObserver$Proxy$_$$_WeldClientProxy.onInstallProjectRequest(KieSessionAsyncJobRequestObserver$Proxy$_$$_WeldClientProxy.java)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at org.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:267)
	at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:52)
	at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:137)
	at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:263)
	at org.jboss.weld.introspector.jlr.WeldMethodImpl.invokeOnInstance(WeldMethodImpl.java:170)
	at org.jboss.weld.introspector.ForwardingWeldMethod.invokeOnInstance(ForwardingWeldMethod.java:51)
	at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:154)
	at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:245)
	at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:233)
	at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:213)
	at org.jboss.weld.event.ObserverNotifier.notifyObserver(ObserverNotifier.java:117)
	at org.jboss.weld.event.TransactionalObserverNotifier.notifyObserver(TransactionalObserverNotifier.java:44)
	at org.jboss.weld.event.ObserverNotifier.notifyObservers(ObserverNotifier.java:85)
	at org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:80)
	at org.jboss.weld.event.EventImpl.fire(EventImpl.java:68)
	at org.kie.workbench.common.services.rest.ProjectResource.installProject(ProjectResource.java:378)
	at org.kie.workbench.common.services.rest.ProjectResource$Proxy$_$$_WeldClientProxy.installProject(ProjectResource$Proxy$_$$_WeldClientProxy.java)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:167)
	at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269)
	at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227)
	at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:216)
	at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:542)
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:524)
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:126)
	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208)
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55)
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
	at org.jboss.solder.servlet.exception.CatchExceptionFilter.doFilter(CatchExceptionFilter.java:65)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
	at org.jboss.solder.servlet.event.ServletEventBridgeFilter.doFilter(ServletEventBridgeFilter.java:74)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
	at org.jbpm.designer.web.filter.impl.PluggableFilter.doFilter(PluggableFilter.java:70)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
	at org.uberfire.security.server.UberFireSecurityFilter.doFilter(UberFireSecurityFilter.java:254)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149)
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:389)
	at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50)
	at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50)
	at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:336)
	at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856)
	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653)
	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:920)
	at java.lang.Thread.run(Thread.java:724)

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:

Actual results:

Expected results:

Additional info:
Comment 1 Ivo Bek 2013-08-30 07:36:02 EDT
Created attachment 792129 [details]
Part of server log
Comment 2 Ivo Bek 2013-08-30 09:33:44 EDT
This issue happens only when you start bpms with standalone.xml .... running bpms with standalone-full.xml works well.
Comment 3 Jiri Locker 2013-08-30 13:50:47 EDT
(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.
Comment 4 Ivo Bek 2013-09-09 09:25:09 EDT
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.
Comment 5 Ivo Bek 2013-09-09 09:30:42 EDT
This approach is just my way how to deal with the issue. I don't recommend to implement it this way ;)
Comment 6 Alexandre Porcelli 2013-09-17 15:18:50 EDT
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 "" -d '{}'
Comment 7 Ivo Bek 2013-09-18 07:29:11 EDT
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.
Comment 10 Ivo Bek 2013-09-19 09:00:40 EDT
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?
Comment 11 Ivo Bek 2013-09-19 09:05:05 EDT
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.
Comment 12 Alexandre Porcelli 2013-09-19 09:13:33 EDT
IIRC this piece of code follows NIO2 semantics, but I'm fine to remove it (doesn't have any impact anyway).

Comment 16 Ivo Bek 2013-10-15 07:25:13 EDT
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?
Comment 17 Ivo Bek 2013-10-21 09:40:02 EDT
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
Comment 18 Alexandre Porcelli 2013-10-23 08:04:08 EDT
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?
Comment 19 Ivo Bek 2013-10-23 08:25:49 EDT
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.."
Comment 20 Ivo Bek 2013-10-23 08:26:22 EDT
Created attachment 815377 [details]
"FileSystem is close" screenshot
Comment 21 Ivo Bek 2013-10-23 08:30:52 EDT
To make it clear, in the point #7 I mean to repeat the points #3, #4, and #5.
Comment 22 Ivo Bek 2013-10-23 10:32:13 EDT
My environment is Fedora 19 with OpenJDK 1.7. I'll record the process in video.
Comment 23 Alexandre Porcelli 2013-10-23 13:29:02 EDT

 Thanks for the detailed steps now I could reproduce it!

 Fix is already pushed in UberFire repository master and 0.3.x branches:

Comment 24 Ivo Bek 2013-10-24 03:58:34 EDT
That's great news, thank you, I recorded the video but it has 25MB so I couldn't upload it here.
Comment 25 Alexandre Porcelli 2013-11-17 17:59:49 EST
More fixes for this issue, pushed to Uberfire master and 0.3.x branch

Comment 26 Ivo Bek 2013-12-05 05:23:36 EST
Verified in BPMS 6.0.0.ER5

Note You need to log in before you can comment on or make changes to this bug.