jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@gmail.com>
Subject Re: clustered environment, 2 different jvms, TransientFileFactory, storing file blobs in db
Date Thu, 08 Apr 2010 07:59:39 GMT
On Wed, Apr 7, 2010 at 8:21 PM, Adrien Lamoureux
<lamoureux.adrien@gmail.com> 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/blobs
> are implemented 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>.
> Our application connects to one of the standalone instances
> remotely(webdavex) for authoring content, and sends publish instructions
> (via JMS/activemq) to the other.
> The problem though, is that BLOBInTempFile.getStream is occasionaly throwing
> : "file backing binary value not found", and one of the instances sometimes
> can't read the file.
> I've searched and found this information:
> http://mail-archives.apache.org/mod_mbox//jackrabbit-dev/200603.mbox/<90a8d1c00603150237t4c81df4fx178fcd726a93fe@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
> delete files that were created by the other at some DIFFERENT random time
> 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]:

[...] is guaranteed that:
1. The file denoted by the returned abstract pathname did not exist
before this method was invoked


[0] http://java.sun.com/javase/7/docs/api/java/io/File.html#createTempFile(java.lang.String,
java.lang.String, java.io.File)

> I've also attached your Repository.xml that we use for both (with different
> 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 same
> way for e
> Thanks.

View raw message