Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Date: Wed, 9 Nov 2011 17:17:52 +0000 (UTC)
From: "Titu Petrea (Commented) (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Message-ID: 
 <1645552820.14872.1320859072171.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (JCR-2596) multiple instances of
 jackrabbit-standalone cause "file backing binary value not found" from
 org.apache.jackrabbit.util.TransientFileFactory
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/JCR-2596?page=3Dcom.atlassian.j=
ira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D131471=
66#comment-13147166 ]=20

Titu Petrea commented on JCR-2596:
----------------------------------

Is it possible that a clean up job to delete files in the tmp folder ?

On 09.11.2011, at 09:23, "Yuri Sarbaev (Commented) (JIRA)"


               =20
> multiple instances of jackrabbit-standalone cause "file backing binary va=
lue not found" from org.apache.jackrabbit.util.TransientFileFactory
> -------------------------------------------------------------------------=
-------------------------------------------------------------------
>
>                 Key: JCR-2596
>                 URL: https://issues.apache.org/jira/browse/JCR-2596
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-jcr-commons
>    Affects Versions: 2.0
>         Environment: any
>            Reporter: Adrien Lamoureux
>
> running 2 or more instances of jackrabbit-standalone causes file deletion=
s in the temporary folder used by another standalone instance. (when garbag=
e collected)
> To reproduce, run 2 or more instances, create files in each, and then sto=
p one of them and attempt read cached files by the other. The one that stop=
ped will garbage collect files used by the other. This may be hard to repro=
duce, as it doesn't seem to be guaranteed to have a collision on file names=
. The problem "went away" when I forced each instance to use a different te=
mporary folder. But this is not a permanent solution.
> Ex:
> java -Dhostname=3Dstandalonejcr -Djava.io.tmpdir=3D/tmp1 -Xmn100M -Xms500=
M -Xmx500M -jar jackrabbit-standalone-2.0.0.jar -p 8000 -r jcr-repository=
=20
> java -Dhostname=3Dstandalonejcr -Djava.io.tmpdir=3D/tmp2 -Xmn100M -Xms500=
M -Xmx500M -jar jackrabbit-standalone-2.0.0.jar -p 8001 -r jcr-repository=
=20
> Original Emails: (to jackrabbit dev mailing list)
> >>>>>>>>>>>
> Wed, Apr 7, 2010 at 11:21 AM
> subject=09clustered environment, 2 different jvms, TransientFileFactory, =
storing file blobs in db
> Hello,
> I would normally file a bug on jira, but its very difficult to setup/repr=
oduce, so I'm looking for insight first on how temp files/blobs are impleme=
nted in jackrabbit.
> We currently run 2 different "standalone" instances of jackrabbit version=
 2.0.0, each in their own JVM and setup the same way in using <cluster>.=20
> Our application connects to one of the standalone instances remotely(webd=
avex) for authoring content, and sends publish instructions (via JMS/active=
mq) to the other.
> The problem though, is that BLOBInTempFile.getStream is occasionaly throw=
ing : "file backing binary value not found", and one of the instances somet=
imes can't read the file.
> I've searched and found this information:
> http://mail-archives.apache.org/mod_mbox//jackrabbit-dev/200603.mbox/<90a=
8d1c00603150237t4c81df4fx178fcd726a93fe@mail.gmail.com>
> So apparently, when files are read/written, you create a temporary cache,=
 but TransientFileFactory runs as a singleton within a single JVM correct?
> So can I assume that one of the "singletons", (there will be 2??) will de=
lete files that were created by the other at some DIFFERENT random time whe=
n the garbage collector runs?
> I've also attached your Repository.xml that we use for both (with differe=
nt cluster ids of course)
> Adrien
> Thanks
> Is there some way to avoid this??
> I've attached our repository.xml for you to look at, both are setup the s=
ame way for e
> Thanks.
> >>>>>>>>>>>>
> from=09Stefan Guggisberg=20
> reply-to=09dev@jackrabbit.apache.org
> to=09dev@jackrabbit.apache.org
> date=09Thu, Apr 8, 2010 at 12:59 AM
> subject=09Re: clustered environment, 2 different jvms, TransientFileFacto=
ry, storing file blobs in db
> On Wed, Apr 7, 2010 at 8:21 PM, Adrien Lamoureux
> wrote:
> > Hello,
> > I would normally file a bug on jira, but its very difficult to
> > setup/reproduce, so I'm looking for insight first on how temp files/blo=
bs
> > are implemented in jackrabbit.
> > We currently run 2 different "standalone" instances of jackrabbit versi=
on
> > 2.0.0, each in their own JVM and setup the same way in using <cluster>.
> > Our application connects to one of the standalone instances
> > remotely(webdavex) for authoring content, and sends publish instruction=
s
> > (via JMS/activemq) to the other.
> > The problem though, is that BLOBInTempFile.getStream is occasionaly thr=
owing
> > : "file backing binary value not found", and one of the instances somet=
imes
> > can't read the file.
> > I've searched and found this information:
> > http://mail-archives.apache.org/mod_mbox//jackrabbit-dev/200603.mbox/<9=
0a8d1c00603150237t4c81df4fx178fcd726a93fe@mail.gmail.com>
> > So apparently, when files are read/written, you create a temporary cach=
e,
> > but TransientFileFactory runs as a singleton within a single JVM correc=
t?
> yes
> > So can I assume that one of the "singletons", (there will be 2??) will
> > delete files that were created by the other at some DIFFERENT random ti=
me
> > when the garbage collector runs?
> no, unless java.io.File#createTempFile invoked from 2 different jvm's
> would create
> colliding temp files. but that's impossible according to the javadoc [0]:
> <quote>
> [...] is guaranteed that:
> 1. The file denoted by the returned abstract pathname did not exist
> before this method was invoked
> [...]
> </quote>
> cheers
> stefan
> [0] http://java.sun.com/javase/7/docs/api/java/io/File.html#createTempFil=
e(java.lang.String,
> java.lang.String, java.io.File)
> >>>>>>>>>>>>
> from=09Thomas M=C3=BCller=20
> reply-to=09dev@jackrabbit.apache.org
> to=09dev@jackrabbit.apache.org
> date=09Thu, Apr 8, 2010 at 1:52 AM
> subject=09Re: clustered environment, 2 different jvms, TransientFileFacto=
ry, storing file blobs in db
> Hi,
> Stefan is right, File.createTempFile() doesn't generate colliding
> files. However, there is a potential problem with the
> TransientFileFactory. Consider the following case:
> - The file "bin-1.tmp" is created (BLOBInTempFile line 51).
> - The TransientFileFactory adds a PhantomReference "A" in its queue.
> - BLOBInTempFile.delete() or dispose() is called, the file "bin-1.tmp"
> is deleted.
> - A new file is created, and also called "bin-1.tmp" is created
> (BLOBInTempFile line 51)
>  (that's possible because File.createTempFile can re-use file names).
> - The TransientFileFactory adds a second PhantomReference "B" in its
> queue, pointing
>  to a different file with the same name.
> - The first (only the first) BLOBInTempFile is no longer referenced.
> - The TransientFileFactory.ReaperThread gets PhantomReference "A" and
>  deletes this file. But the file is still used and referenced ("B").
> I'm not sure if this is what is happening in your case, but it is a
> potential problem.
> Could you log a bug?
> There are multiple ways to solve the problem. I think the best
> solution is to not use File.createTempFile() and instead use our own
> file name factory (with a random part, and an counter part).
> Regards,
> Thomas

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrato=
rs: https://issues.apache.org/jira/secure/ContactAdministrators!default.jsp=
a
For more information on JIRA, see: http://www.atlassian.com/software/jira