commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cservenak Tamas <cserve...@is-micro.hu>
Subject Re: [transaction] FileNotFoundException during commitTransaction()
Date Tue, 22 Nov 2005 19:17:51 GMT
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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message