Just a note (may be interesting):
After that FRM throws exception and my app stops, the FRM performs a
normal shutdown and JVM cleanly exits.
Upon exit, the file reported in FileNotFoundException APPEARS on the
right place reported in exception as missing! (it is placed there
DURING shutdown/cleanup of FRM).
It seems that this error have some sort of stochastic nature, i am
trying to reproduce it now, but no luck :)
My experience was that this error shows up as we optimized/speed up the
app. Now we have 1500 file/sec throughoutput (from the aspect of app),
so we have cca 6000 tx/sec minimum.
~t~
Cservenak Tamas wrote:
Hi Oliver!
I'm am positively sure about #2. I have NO ACCESS to FS except thru FRM.
And plus, the whole txfs/store and txfs/work (the store and workdir of
FRM) is isolated, it is not used by direct File access.
(second para) Not quite. This error happened on any stage (i have 4 of
them) on OUTPUT side of it. The error happened on the side where we are
PLACING files, not taking.
To clear this up:
One Stage works like this:
doBeforeTx() {
resId = queue.get();
}
superclass.startTx();
doInTx() {
frm.readResource(INPUT_PREFIX + resid);
do smthng with resId over frm,
frm.writeRes( OUTPUT_PREFIXresId)
}
superclass.commit();
doAfterTx() {
queue.put(resId)
}
INPUT_PREFIX and OUTPUT_PREFIX are not constants actually, they are set
up on startup. The materialization of this is like series of dirs, and
files are travelling from dir to dir, as they advance from stage to stage.
So, the error always happens on the LEFT side (while commit - write) of
files, not RIGHT side (read). As pseudocode says, the RIGHT side even
does not know about the resId (it is not sent over queue!).....
Remember, it dies in
new FileOUTPUTStream(File)...
The exact location will be in stack trace....
Stack trace follows in a moment.
~t~
Oliver Zeigermann wrote:
Hi,
I looked at the code of commit and it really looks ok. Is it always
the same file (or same category of file) that is not found?
FileHelper.moveRec is only called from inside of
TransactionContext.commit which is synchronized on the context. This
means if a file that should be there no longer exists has probably
been deleted in between finding the children of a folder and iterating
through it. This can only be done by a second thread which should not
have any access to the directory of this transaction.
Note #1: That two transactions running on the same store dir can not
interfere while committing as this is prevented by locks.
Note #2: No other process/thread/whatever may access the store
directory that FRM is working on.
Are you sure that #2 is guaranteed in your application?
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
|
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
