You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Giota Karadimitriou <Gi...@eurodyn.com> on 2006/03/14 11:19:36 UTC
binary values problem
Hello,
We have re-deployed our web application (ear) and have run across the
following problem:
Probably because of the forced shutdown and even though we use
transactional PM (SimpleDBPersistenceManager)
with <param name="externalBLOBs" value="false"/>
and jackrabbit as RAR (using the JCA package)--all these in order to
enforce transactional behaviour which will be handled by the
application-server and not the application explicitly, the resource
nodes(nt:resource) we had under certain files seem to be corrupted.
When we try to access a file with such a resource we get an exception
Caused by: javax.jcr.RepositoryException: file backing binary value not
found: C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\1\bin14955.tmp (The system
cannot find the file specified):
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\1\bin14955.tmp (The system cannot
find the file specified)
at
org.apache.jackrabbit.core.value.BLOBFileValue.getStream(BLOBFileValue.j
ava:453)
at
org.apache.jackrabbit.core.value.InternalValue.toJCRValue(InternalValue.
java:325)
at
org.apache.jackrabbit.core.PropertyImpl.getValue(PropertyImpl.java:500)
at
org.apache.jackrabbit.core.PropertyImpl.getStream(PropertyImpl.java:540)
.
Indeed this tmp file that the application is referring to, does not
exist.
I can fix this situation for the time being by cleaning up the
repository however this could never be done in a production environment.
Could someone please provide me with some more insight on how the binary
values are exactly stored and what could go wrong with forced shutdown?
Why does jackrabbit search for this temp file when it has already stored
the binary value in DEFAULT_BINVAL table? Is there any way to overcome a
problem such as the described one?
regards
Giota
Re: binary values problem
Posted by Tobias Bocanegra <to...@day.com>.
hi giotta,
> 1) The ReferentialIntegrityException which should not be thrown and
this one is already filed here: http://issues.apache.org/jira/browse/JCR-272
> 2) Somehow "restore" is not rolled-back when an exception occurs
> (sth that should not happen with jca).
i created a new issue for this: http://issues.apache.org/jira/browse/JCR-362
regards, toby
--
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---
RE: binary values problem
Posted by Giota Karadimitriou <Gi...@eurodyn.com>.
After running a few tests, I was able to re-produce this problem.
The problem was caused when our application was trying to remove the
last version of a node. To accomplish the removal of the last version, I
was first restoring to the previous version and then removing the last
Version version = vh.getVersionByLabel(versionLabel);
Version lastVersion=n.getBaseVersion();
if (version.equals(lastVersion)) {
n.restore(version.getPredecessors()[0],true);
vh.removeVersion(version.getName());
}
I ran the above code with a standalone test application I have and it
ran fine. However when our application ran this code through application
server with jackrabbit configured as resource-adapter using JCA, it
failed while executing the last line of code, with
ReferentialIntegrityException
"Unable to remove version. At least once referenced."
This mistake prevented the transaction from concluding (commiting).
When I then performed normal server shutdown and re-started the
application, it complained about not finding some temp file
Caused by: javax.jcr.RepositoryException: file backing binary value not
> found: C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\1\bin14955.tmp (The system
> cannot find the file specified):
> C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\1\bin14955.tmp (The system cannot
> find the file specified)
> at
>
org.apache.jackrabbit.core.value.BLOBFileValue.getStream(BLOBFileValue.j
> ava:453)...
**Therefore the existing problems are two.
1) The ReferentialIntegrityException which should not be thrown and
2) Somehow "restore" is not rolled-back when an exception occurs
(sth that should not happen with jca).
I had similar results (tmp files) when I did
...
Object nullString=null;
if (version.equals(lastVersion)) {
n.restore(version.getPredecessors()[0],true);
System.out.println(nullString.toString()); //cause an exception
}
Regarding the first problem now (referential integrity)
I had similar problems in the past with JCA and operations that write
directly to the workspace and do not require a session.save.
When using JCA, the transactions are handled by the application server
(container) and operations (even the ones that write directly to the
workspace) are not persisted until the end of the transactions. However
some checks that jackrabbit performs -like checking if any references
(from outside the version storage) exist on this version (in class
InternalVersionHistoryImpl) are still ran thus causing exception and
preventing the flow.
List refs = vMgr.getItemReferences(v);
if (!refs.isEmpty()) {
throw new ReferentialIntegrityException("Unable to
remove version. At least once referenced.");
}
I do not know if this behaviour is linked to other jackrabbit versioning
bugs which remain unsolved like 335 or 50.
The only thing I can think of in order to prevent the 2 above problems
is to comment the above code in class InternalVersionHistoryImpl. I know
this would be a mistake since the referential integrity check is
necessary, however I need the 'remove version' functionality in my
application and do not want to encounter any more of this tmp file
problems in the future. If you can think of any other workaround please
let me know.
I just thought to report it to the list so that you know of this
behavior and maybe take corrective action against it in the future.
Regards
Giota
-----Original Message-----
From: Stefan Guggisberg [mailto:stefan.guggisberg@gmail.com]
Sent: Wednesday, March 15, 2006 12:37 PM
To: jackrabbit-dev@incubator.apache.org
Subject: Re: binary values problem
hi giota
On 3/14/06, Giota Karadimitriou <Gi...@eurodyn.com> wrote:
> Hello,
>
> We have re-deployed our web application (ear) and have run across the
> following problem:
>
> Probably because of the forced shutdown and even though we use
> transactional PM (SimpleDBPersistenceManager)
> with <param name="externalBLOBs" value="false"/>
> and jackrabbit as RAR (using the JCA package)--all these in order to
> enforce transactional behaviour which will be handled by the
> application-server and not the application explicitly, the resource
> nodes(nt:resource) we had under certain files seem to be corrupted.
>
> When we try to access a file with such a resource we get an exception
>
>
> Caused by: javax.jcr.RepositoryException: file backing binary value
not
> found: C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\1\bin14955.tmp (The system
> cannot find the file specified):
> C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\1\bin14955.tmp (The system cannot
> find the file specified)
> at
>
org.apache.jackrabbit.core.value.BLOBFileValue.getStream(BLOBFileValue.j
> ava:453)
> at
>
org.apache.jackrabbit.core.value.InternalValue.toJCRValue(InternalValue.
> java:325)
> at
>
org.apache.jackrabbit.core.PropertyImpl.getValue(PropertyImpl.java:500)
> at
>
org.apache.jackrabbit.core.PropertyImpl.getStream(PropertyImpl.java:540)
> .
>
> Indeed this tmp file that the application is referring to, does not
> exist.
>
> I can fix this situation for the time being by cleaning up the
> repository however this could never be done in a production
environment.
>
> Could someone please provide me with some more insight on how the
binary
> values are exactly stored and what could go wrong with forced
shutdown?
binary values are immediately streamed to a temp file when they are set
(e.g. using node.setProperty("bin", stream)).
this 'internal' value will be persisted on save().
a forced shutdown should not affect the repository integrity provided
that
the binaries are stored in the db.
> Why does jackrabbit search for this temp file when it has already
stored
> the binary value in DEFAULT_BINVAL table?
when a binary value is read from the db it is streamed to a temp file
to allow for caching and repeatable reads.
> Is there any way to overcome a problem such as the described one?
personally i am not aware of any such issue.
please file a jira bug and provide a simple test case & configuration
if you can easily reproduce this issue.
cheers
stefan
>
> regards
> Giota
>
>
Re: binary values problem
Posted by Stefan Guggisberg <st...@gmail.com>.
hi giota
On 3/14/06, Giota Karadimitriou <Gi...@eurodyn.com> wrote:
> Hello,
>
> We have re-deployed our web application (ear) and have run across the
> following problem:
>
> Probably because of the forced shutdown and even though we use
> transactional PM (SimpleDBPersistenceManager)
> with <param name="externalBLOBs" value="false"/>
> and jackrabbit as RAR (using the JCA package)--all these in order to
> enforce transactional behaviour which will be handled by the
> application-server and not the application explicitly, the resource
> nodes(nt:resource) we had under certain files seem to be corrupted.
>
> When we try to access a file with such a resource we get an exception
>
>
> Caused by: javax.jcr.RepositoryException: file backing binary value not
> found: C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\1\bin14955.tmp (The system
> cannot find the file specified):
> C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\1\bin14955.tmp (The system cannot
> find the file specified)
> at
> org.apache.jackrabbit.core.value.BLOBFileValue.getStream(BLOBFileValue.j
> ava:453)
> at
> org.apache.jackrabbit.core.value.InternalValue.toJCRValue(InternalValue.
> java:325)
> at
> org.apache.jackrabbit.core.PropertyImpl.getValue(PropertyImpl.java:500)
> at
> org.apache.jackrabbit.core.PropertyImpl.getStream(PropertyImpl.java:540)
> .
>
> Indeed this tmp file that the application is referring to, does not
> exist.
>
> I can fix this situation for the time being by cleaning up the
> repository however this could never be done in a production environment.
>
> Could someone please provide me with some more insight on how the binary
> values are exactly stored and what could go wrong with forced shutdown?
binary values are immediately streamed to a temp file when they are set
(e.g. using node.setProperty("bin", stream)).
this 'internal' value will be persisted on save().
a forced shutdown should not affect the repository integrity provided that
the binaries are stored in the db.
> Why does jackrabbit search for this temp file when it has already stored
> the binary value in DEFAULT_BINVAL table?
when a binary value is read from the db it is streamed to a temp file
to allow for caching and repeatable reads.
> Is there any way to overcome a problem such as the described one?
personally i am not aware of any such issue.
please file a jira bug and provide a simple test case & configuration
if you can easily reproduce this issue.
cheers
stefan
>
> regards
> Giota
>
>