-
1. Re: Problem with BasicXARecoveryTest and Paging
clebert.suconic Nov 8, 2008 11:07 PM (in response to timfox)If this can wait until Tuesday, I could take a look when I'm back from a short trip.
-
2. Re: Problem with BasicXARecoveryTest and Paging
timfox Nov 12, 2008 10:23 AM (in response to timfox)Is anyone looking at this? Andy? Clebert?
-
3. Re: Problem with BasicXARecoveryTest and Paging
clebert.suconic Nov 12, 2008 12:40 PM (in response to timfox)I'm looking it
-
4. Re: Problem with BasicXARecoveryTest and Paging
clebert.suconic Nov 12, 2008 1:24 PM (in response to timfox)The problem was with some of the recent changes, the ACKs were being batched per ACKBatchSize on the client, never releasing the queue what caused the messages to hang on paging.
And BTW: Is the semantic on createSession(boolean xa, boolean autoCommitSends, boolean autoCommitAcks) correct?
I expected autoCommitACKs=true => not batching ACKs? I've tried using it and I had actually to force a commit call. -
5. Re: Problem with BasicXARecoveryTest and Paging
timfox Nov 12, 2008 2:52 PM (in response to timfox)"clebert.suconic@jboss.com" wrote:
The problem was with some of the recent changes, the ACKs were being batched per ACKBatchSize on the client, never releasing the queue
I'm not sure what you mean by "never releasing the queue"... can you explain some more? -
6. Re: Problem with BasicXARecoveryTest and Paging
timfox Nov 12, 2008 2:53 PM (in response to timfox)"clebert.suconic@jboss.com" wrote:
I expected autoCommitACKs=true => not batching ACKs?
No, autocommit acks means acks are processed before transaction commit.
Flushing flushes acks to the server, -
7. Re: Problem with BasicXARecoveryTest and Paging
clebert.suconic Nov 12, 2008 2:56 PM (in response to timfox)I meant to say "never releasing messages from the queue"
Paging works based on Memory usage.
As you ACK messages, removing and eliminating messages from the memory, you get more messages out of paging. (or else you could get an OutOfMemoryException).
The test was never ACKing messages, and because of that the test was never depaging.
I still have a question about the semantics on createSession (...., autoCommitACKs)... if we should still batch ACKs when autoCommitACK==true. -
8. Re: Problem with BasicXARecoveryTest and Paging
clebert.suconic Nov 12, 2008 2:58 PM (in response to timfox)"timfox" wrote:
"clebert.suconic@jboss.com" wrote:
I expected autoCommitACKs=true => not batching ACKs?
No, autocommit acks means acks are processed before transaction commit.
Flushing flushes acks to the server,
Is there any equivalent to the JMS Session.AUTO_ACKNOWLEDGE on the core-api? Or we aways have to explicitly ACK when not using JMS? -
9. Re: Problem with BasicXARecoveryTest and Paging
timfox Nov 12, 2008 2:58 PM (in response to timfox)"clebert.suconic@jboss.com" wrote:
I meant to say "never releasing messages from the queue"
Paging works based on Memory usage.
As you ACK messages, removing and eliminating messages from the memory, you get more messages out of paging. (or else you could get an OutOfMemoryException).
The test was never ACKing messages, and because of that the test was never depaging..
But that shouldn't cause NPEs, or weird IllegalMonitorStateExceptions....
It's quite normal that the server should be able to cope with many thousands of unacked messages. -
10. Re: Problem with BasicXARecoveryTest and Paging
timfox Nov 12, 2008 2:59 PM (in response to timfox)"clebert.suconic@jboss.com" wrote:
I still have a question about the semantics on createSession (...., autoCommitACKs)... if we should still batch ACKs when autoCommitACK==true.
The two things are orthogonal. -
11. Re: Problem with BasicXARecoveryTest and Paging
timfox Nov 12, 2008 3:00 PM (in response to timfox)"clebert.suconic@jboss.com" wrote:
Is there any equivalent to the JMS Session.AUTO_ACKNOWLEDGE on the core-api? Or we aways have to explicitly ACK when not using JMS?
Acking is always explicit -
12. Re: Problem with BasicXARecoveryTest and Paging
clebert.suconic Nov 12, 2008 5:13 PM (in response to timfox)"timfox" wrote:
But that shouldn't cause NPEs, or weird IllegalMonitorStateExceptions....
I found a problem with journalImpl.stop().
It's not using any of the locks, and that is changing currentFile, closing files without wait for current operations to finish.
I'm fixing it and writing a test for that. -
13. Re: Problem with BasicXARecoveryTest and Paging
clebert.suconic Nov 12, 2008 9:50 PM (in response to timfox)I have fixed the root cause of those NPEs on my local copy, however I want to make sure I didn't break anything... so I will hold of the commit until I'm sure about the fix:
https://jira.jboss.org/jira/browse/JBMESSAGING-1450 -
14. Re: Problem with BasicXARecoveryTest and Paging
timfox Nov 13, 2008 5:11 AM (in response to timfox)"clebert.suconic@jboss.com" wrote:
I found a problem with journalImpl.stop().
It's not using any of the locks, and that is changing currentFile, closing files without wait for current operations to finish.
That would probably explain the NPEs and IllegalMonitorStateExceptions I've been seeing.