Problem with BasicXARecoveryTest and Paging

[timfox]

https://jira.jboss.org/jira/browse/JBMESSAGING-1449

Maybe I have broken something, but it's not immediately obvious. Paging seems to fail with either a NPE or IllegalMonitorStateException or some other error randomly.

I have commented out those tests until this is resolved.

Can someone take a look?

[clebert.suconic]

If this can wait until Tuesday, I could take a look when I'm back from a short trip.

[timfox]

Is anyone looking at this? Andy? Clebert?

[clebert.suconic]

I'm looking it

[clebert.suconic]

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.

[timfox]

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?

[timfox]

I expected autoCommitACKs=true => not batching ACKs?

No, autocommit acks means acks are processed before transaction commit.

Flushing flushes acks to the server,

[clebert.suconic]

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.

[clebert.suconic]

"timfox" 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?

[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..

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.

[timfox]

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.

[timfox]

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

[clebert.suconic]

"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.

[clebert.suconic]

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

[timfox]

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.