Re: [jboss-dev-forums] [JBoss Microcontainer Development] - VFS3 and symlinks
by Rainer Meier
Rainer Meier [http://community.jboss.org/people/SkyBeam] replied to the discussion
"VFS3 and symlinks"
To view the discussion, visit: http://community.jboss.org/message/549517#549517
--------------------------------------------------------------
It seems my previous analysis was not entirely correct.
I just noticed that I did not install jboss-vfs.jar in version 2.2.0.GA but instead I've installed version 2.2.0.M4 from the official Maven repository ( http://repository.jboss.org/maven2/org/jboss/jboss-vfs/2.2.0.M4/ http://repository.jboss.org/maven2/org/jboss/jboss-vfs/2.2.0.M4/). Then I found out that version 2.2.0.GA can be found at http://repository.jboss.org/maven2-brew/org/jboss/jboss-vfs/2.2.0.GA/ http://repository.jboss.org/maven2-brew/org/jboss/jboss-vfs/2.2.0.GA/ (I hope this is the correct location). Just wondering why it's not in the official maven2 location.
After installing this version and setting the default vfs.xml configuration and adding the -Djboss.vfs.forceCanonical=true startup parameter it seems to work fine. Even if I use the jboss.server.home.url property in vfs.xml.
Here's my vfs.xml property for reference:
<?xml version="1.0" encoding="UTF-8"?><!-- The JBossVFS initializer configuration.--><deployment xmlns="urn:jboss:bean-deployer:2.0"> <bean name="VFSCache"> <constructor factoryClass="org.jboss.virtual.spi.cache.VFSCacheFactory" factoryMethod="getInstance"> <!-- Use the CombinedVFSCache implementation --> <parameter>org.jboss.virtual.plugins.cache.CombinedVFSCache</parameter> </constructor> <start ignored="true"/> <property name="permanentRoots"> <map keyClass="java.net.URL" valueClass="org.jboss.virtual.spi.ExceptionHandler"> <entry> <key>${jboss.lib.url}</key> <value><null/></value> </entry> <entry> <key>${jboss.common.lib.url}</key> <value><inject bean="VfsNamesExceptionHandler"/></value> </entry> <entry> <key>${jboss.server.lib.url}</key> <value><inject bean="VfsNamesExceptionHandler"/></value> </entry> <entry> <key>${jboss.server.home.url}deploy</key> <value><inject bean="VfsNamesExceptionHandler"/></value> </entry> <entry> <key>${jboss.server.home.url}farm</key> <value><inject bean="VfsNamesExceptionHandler"/></value> </entry> </map> </property> <property name="realCache"> <bean/> </property> </bean> <bean name="VfsNamesExceptionHandler"> <constructor> <parameter>sqljdbc.jar</parameter> </constructor> </bean></deployment>
Reading this thread it looks to me that some people seem to be concerned about possible performance drop when using/enforcing canonical names. Is this likely to be a real issue or just a small impact?
Personally I think it will not be a big issue at runtime. Maybe a small impact during startup and deployment when canonical paths of the files need to be looked up. But after deployment there should not be much canonical path lookups required.
What do you think about? Or are there any benchmarks done with or without this option being enabled?
I am running JBoss 5.1.0 on Solaris 10 x86 (if this is relevant).
Thanks again for your help.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/549517#549517]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 3 months
Re: [jboss-dev-forums] [JBoss Microcontainer Development] - VFS3 and symlinks
by Rainer Meier
Rainer Meier [http://community.jboss.org/people/SkyBeam] replied to the discussion
"VFS3 and symlinks"
To view the discussion, visit: http://community.jboss.org/message/549453#549453
--------------------------------------------------------------
> You can update the AS5.1's VFS to 2.2.0.GA and use the -Djboss.vfs.forceCanonical=true.
Thanks a lot for the hint.
If I understand correctly this also means that I will have to insret canonical paths to vfs.xml like this:
<entry> <key>file:/opt/app/4.0/server/app/deploy</key> <value><inject bean="VfsNamesExceptionHandler"/></value> </entry> <entry> <key>file:/opt/app/4.0/server/app/farm</key> <value><inject bean="VfsNamesExceptionHandler"/></value> </entry>
"Unfortunately" the app is also relocatable so providing absolute paths within vfs.xml is not a good idea during deployment since the app might also be installed at /opt/xy/app or /usr/local/app or somewhere else.
I just tried to use the default notation in vfs.xml:
<entry>
<key>${jboss.server.home.url}deploy</key>
<value><inject bean="VfsNamesExceptionHandler"/></value>
</entry>
<entry>
<key>${jboss.server.home.url}farm</key>
<value><inject bean="VfsNamesExceptionHandler"/></value>
</entry>
But after 1 hour it started to grow again. So it seems that jboss.server.home.url is probably not expanded as a canonical path and therefore it does not match. Is this a bug or am I just misunderstanding the functionality here?
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/549453#549453]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 3 months
Re: [jboss-dev-forums] [JBoss Microcontainer Development] - VFS3 and symlinks
by Rainer Meier
Rainer Meier [http://community.jboss.org/people/SkyBeam] replied to the discussion
"VFS3 and symlinks"
To view the discussion, visit: http://community.jboss.org/message/549424#549424
--------------------------------------------------------------
I am facing the same problem here and this thread seems to describe the source of my problems but it also seems that people lost interest in the discussion. Does anybody know the status of these VFS3 issues? Any fix available?
Currently I am running a stand-alone JBoss instance installed at /opt/jboss/5.1.0/. We run an application which installs itself to /opt/app/4.0/server/app (the complete JBoss configuration is deployed there). So the instlalation package creates a symlink:
/opt/jboss/5.1.0/server/app -> /opt/app/current/server/app
Note: That /opt/app/current is a symlink on its own pointing to the current app version, currently current points to the 4.0 folder at the same level:
/opt/app/current -> 4.0
Then JBoss is launched with the "-c app" parameter.
After about 1 hour the tmp/vfs-nested.tmp/ folder is starting to grow until it fills up the whole disk (>100GB).
I've tried a couple of settings. For example I've tried to extend vfs.xml to include the canonical URLs as well:
{code:xml}
<entry>
<entry>
<key>file:/opt/app/4.0/server/app/deploy</key>
<value><inject bean="VfsNamesExceptionHandler"/></value>
</entry>
<entry>
<key>file:/opt/app/4.0/server/app/farm</key>
<value><inject bean="VfsNamesExceptionHandler"/></value>
</entry>
<entry>
<key>file:/opt/app/current/server/app/deploy</key>
<value><inject bean="VfsNamesExceptionHandler"/></value>
</entry>
<entry>
<key>file:/opt/app/current/server/app/farm</key>
<value><inject bean="VfsNamesExceptionHandler"/></value>
</entry>
{code}
But it did not help at all.
I also tried to play with JBoss properties to have it pointing directly to the physical server configuration directory by appending
"-Djboss.server.base.dir='/opt/app/current/server/' -Djboss.server.base.url='file:/opt/app/current/server/'
to the sartup options. This makes JBoss read the configuration directly from /opt/app/current/server but still no go, tmp/vfs-nested.tmp/ is still growing after a while.
Does anybody have any hints what I have to configure to make VFS work as expected in this situation?
Copying the whole /opt/app/current/server/app folder to /opt/jboss/5.1.0/server/ works as expected, so it's not an application issue. However the package of this application will maintain the files at /opt/app and therefore a simple symlink would be much easier from maintenance point of view. If the whole application needs to be copied it will have to be duplicated after each package/patch installation.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/549424#549424]
Start a new discussion in JBoss Microcontainer Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 3 months
[jBPM Development] - Close ProcessEngine upon BPM console undeployment
by Alejandro Guizar
Alejandro Guizar [http://community.jboss.org/people/alex.guizar%40jboss.com] created the discussion
"Close ProcessEngine upon BPM console undeployment"
To view the discussion, visit: http://community.jboss.org/message/549378#549378
--------------------------------------------------------------
Regarding https://jira.jboss.org/browse/JBPM-2881 JBPM-2881, it seems the process engine is not closed when the BPM console is undeployed. ProcessEngineImpl stops the job executor on close. However, the job dispatcher thread is still running after the web application stops, as evidenced by the following stack trace.
22/06/2010 08:43:28 PM org.apache.catalina.loader.WebappClassLoader loadClass
INFO: Illegal access: this web application instance has been stopped already.
Could not load org.jbpm.pvm.internal.tx.StandardTransaction.
The eventual following stack trace is caused by an error thrown for debugging purposes
as well as to attempt to terminate the thread which caused the illegal access,
and has no functional impact.
java.lang.IllegalStateException
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1402)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1361)
at org.jbpm.pvm.internal.util.ReflectUtil.classForName(ReflectUtil.java:453)
at org.jbpm.pvm.internal.wire.descriptor.ObjectDescriptor.construct(ObjectDescriptor.java:141)
at org.jbpm.pvm.internal.wire.WireContext.construct(WireContext.java:487)
at org.jbpm.pvm.internal.wire.WireContext.create(WireContext.java:466)
at org.jbpm.pvm.internal.wire.WireContext.create(WireContext.java:455)
at org.jbpm.pvm.internal.wire.WireContext.get(WireContext.java:429)
at org.jbpm.pvm.internal.wire.WireContext.get(WireContext.java:339)
at org.jbpm.pvm.internal.wire.WireContext.get(WireContext.java:706)
at org.jbpm.pvm.internal.env.BasicEnvironment.get(BasicEnvironment.java:132)
at org.jbpm.pvm.internal.env.BasicEnvironment.get(BasicEnvironment.java:123)
at org.jbpm.pvm.internal.tx.StandardTransactionInterceptor.execute(StandardTransactionInterceptor.java:46)
at org.jbpm.pvm.internal.svc.EnvironmentInterceptor.executeInNewEnvironment(EnvironmentInterceptor.java:53)
at org.jbpm.pvm.internal.svc.EnvironmentInterceptor.execute(EnvironmentInterceptor.java:40)
at org.jbpm.pvm.internal.svc.RetryInterceptor.execute(RetryInterceptor.java:56)
at org.jbpm.pvm.internal.svc.SkipInterceptor.execute(SkipInterceptor.java:43)
at org.jbpm.pvm.internal.jobexecutor.DispatcherThread.acquireJobs(DispatcherThread.java:126)
at org.jbpm.pvm.internal.jobexecutor.DispatcherThread.run(DispatcherThread.java:67)
I did not develop the console integration and lack the knowledge required to place the ProcessEngine.close() call properly. Any pointers in this direction would be very helpful.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/549378#549378]
Start a new discussion in jBPM Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 3 months