-
1. Re: AIO/DirectIO Integration
clebert.suconic Apr 10, 2008 11:53 AM (in response to clebert.suconic)I removed the requirement for the fillerSize, as I have talked to Tim.
Now we aways move to the next position just based on the alignment of the File.
I have committed this work into this Branch:
http://anonsvn.jboss.org/repos/messaging/branches/trunk_tmp_aio/
I still have some work to do, like refactoring on few tests that are dealing with record sizes (what will change when using AIO).
And also, I've found some problem with reclaiming files. The counter doesn't work properly in some situation when the commit is sent to another file. I didn't fully understand the counting, but it looks like there is a problem on the ref count. -
2. Re: AIO/DirectIO Integration
timfox Apr 12, 2008 7:27 AM (in response to clebert.suconic)"clebert.suconic@jboss.com" wrote:
And also, I've found some problem with reclaiming files. The counter doesn't work properly in some situation when the commit is sent to another file. I didn't fully understand the counting, but it looks like there is a problem on the ref count.
Can you be more specific? -
3. Re: AIO/DirectIO Integration
clebert.suconic Apr 24, 2008 7:43 PM (in response to clebert.suconic)Tim Fox wrote:
Can you be more specific?
I just added JournalImplTestUnit::testTransactionOnDifferentFiles, and it is failing.
"Cannot find add info 1."
Note: if you remove the reclaiming call the test will pass. -
4. Re: AIO/DirectIO Integration
clebert.suconic Apr 24, 2008 7:56 PM (in response to clebert.suconic)This is what is happening:
The transactions are being spread multiple files...
And the commit is alone on the last file...
If there is another record (non related to transactionID=1) that file won't be deleted... but all the others are being deleted.
Later when the file is recovered, Commit(1) won't find a previous add.
Maybe those other files shouldn't be released if the commit can't also be released.
Any ideas Tim? -
5. Re: AIO/DirectIO Integration
timfox Apr 25, 2008 2:42 AM (in response to clebert.suconic)The test is illegal, since you're adding record 1 in the same tx as you're deleting it.
In messaging you can't do this (send and consume in the same tx).
If you delete something in a tx it must already exist in committed (not transactional) state.
Actually the test is useful though, can you keep it but change it to assert that the exception is thrown as it currently is? -
6. Re: AIO/DirectIO Integration
clebert.suconic Apr 25, 2008 9:20 AM (in response to clebert.suconic)The test is a simple copy of testMultipleTransactionsDifferentIDs that started to fail when I was using AIO (as it changed the positioning of the records a little bit).
If the test is illegl, a the delete should throw an exception, but the test is failing just because of the position of the commit. In fact I managed to change the test in another way and still fails:addTx(1, 1, 2, 3, 4, 5, 6); updateTx(1, 1, 3, 5); commit(1); deleteTx(2, 1, 2, 3, 4, 5, 6); commit(2); // Just to make sure the commit won't be released. The commit will be on the same file as addTx(3); addTx(3, 11, 12);
-
7. Re: AIO/DirectIO Integration
timfox Apr 25, 2008 9:46 AM (in response to clebert.suconic)If you can create a legal test that fails, that's fine.
But it's just confusing to work on illegal tests. -
8. Re: AIO/DirectIO Integration
clebert.suconic Apr 25, 2008 10:09 AM (in response to clebert.suconic)If you can create a legal test that fails, that's fine.
But it's just confusing to work on illegal tests.
I didn't create the test... just isolated the failure from testMultipleTransactionsDifferentIDs. -
9. Re: AIO/DirectIO Integration
timfox Apr 25, 2008 10:10 AM (in response to clebert.suconic)What I am saying is come up with a *legal* test that fails, and we'll take it from there....