Red Hat Bugzilla – Bug 990575
BPMS should not use system /tmp
Last modified: 2014-08-06 16:15:51 EDT
Created attachment 781133 [details]
ls -la /tmp
BPMS should not use system /tmp. Instead it should use for all temporary data tmp folder of the container, ie. jboss-eap-6.1/standalone/tmp.
Problematic files include
*.bpmn2 and other assets
gitz* they are from bpms as well, but I am not sure of their purpose
*.jar *.pom deployment units
See the attached list of files in my /tmp dir.
There multiple problems which can be observed. Any fresh install of BPMS will still be affected by previous BPMS instances, which is undesired behavior.
/tmp is usually regularly deleted in many cases. Imagine situation where the server goes down, /tmp directory is deleted and system cannot reload active session id from .ser file.
Observed both in BPMS 6 DR6 and jBPM 6 CR1.
it's possible that some files may belong to dashbuilder, but can you please comment on other files mentioned?
(FYI bpms-perf is my project with assets for performance testing, it's not part of the product)
As of dashbuilder, a fix was pushed on last July to avoid the creation of logs files under the /tmp directory: https://github.com/droolsjbpm/jbpm-dashboard/commit/a02b2e8649e5cfd5ee64a03a342716cef8f340c8
However, the application still creates some temporary files under /tmp: graphicElement*.tmp & csv_temp*.csv files which are created by invoking the File.createTempFile method and are marked as "deleteOnExit". So those files are truly temporal since are deleted just after the appserver shutdown.
If we still want those kind of files to be created under the jboss tmp directory one possible way to proceed might be to modify the following java system property: jboss.io.tmpdir=<jboss tmp dir> to force java temp files to be created under the jboss tmp dir
(to change system properties in JBoss please read https://community.jboss.org/wiki/JBossAS7SystemProperties)
David and Michael confirmed that the current files stored in system /tmp are truly temporary.
I consider this bug as verified. (BPMS 6 ER4)
If there will be again the same situation in the future, where a bpms instance will be affected by artifacts left from a previous one, new BZ will be filed.