eolivelli opened a new issue #11002:
URL: https://github.com/apache/pulsar/issues/11002
**Describe the bug**
I have a topic 'MY_QUEUE' with one subscription 'jms-queue' that ends up in
this situation
peekMessages against 'jms-queue' is returning 74:37:-1
but the next available message should be 74:62
```
pulsar-admin topics stats-internal MY_QUEUE
{
"entriesAddedCounter" : 64,
"numberOfEntries" : 64,
"totalSize" : 13634,
"currentLedgerEntries" : 64,
"currentLedgerSize" : 13634,
"lastLedgerCreatedTimestamp" : "2021-06-21T11:14:38.402Z",
"waitingCursorsCount" : 1,
"pendingAddEntriesCount" : 0,
"lastConfirmedEntry" : "74:63",
"state" : "LedgerOpened",
"ledgers" : [ ],
"cursors" : {
"jms-queue" : {
"markDeletePosition" : "74:36",
"readPosition" : "74:64",
"waitingReadOp" : false,
"pendingReadOps" : 0,
"messagesConsumedCounter" : 58,
"cursorLedger" : 75,
"cursorLedgerLastEntry" : 29,
"individuallyDeletedMessages" :
"[(74:37..74:38],(74:39..74:40],(74:41..74:42],(74:43..74:44],(74:45..74:46],(74:47..74:63]]",
"lastLedgerSwitchTimestamp" : "2021-06-21T11:14:38.498Z",
"state" : "Open",
"numberOfEntriesSinceFirstNotAckedMessage" : 28,
"totalNonContiguousDeletedMessagesRange" : 6,
"subscriptionHavePendingRead" : false,
"subscriptionHavePendingReplayRead" : false,
"properties" : { }
},
"transaction-buffer-sub" : {
"markDeletePosition" : "74:-1",
"readPosition" : "74:0",
"waitingReadOp" : false,
"pendingReadOps" : 0,
"messagesConsumedCounter" : 0,
"cursorLedger" : -1,
"cursorLedgerLastEntry" : -1,
"individuallyDeletedMessages" : "[]",
"lastLedgerSwitchTimestamp" : "2021-06-21T11:14:40.444Z",
"state" : "Uninitialized",
"numberOfEntriesSinceFirstNotAckedMessage" : 1,
"totalNonContiguousDeletedMessagesRange" : 0,
"subscriptionHavePendingRead" : false,
"subscriptionHavePendingReplayRead" : false,
"properties" : { }
}
},
"schemaLedgers" : [ ],
"compactedLedger" : {
"ledgerId" : -1,
"entries" : -1,
"size" : -1,
"offloaded" : false,
"underReplicated" : false
}
}
```
After calling "peekMessages" my code creates a Reader at that position, and
it writes (correctly)
`INFO org.apache.pulsar.client.impl.ConsumerImpl -
[persistent://public/default/MY_QUEUE][reader-f65efe6431] Successfully
getLastMessageId 74:62`
There must be some problem in dealing with `individuallyDeletedMessages`,
but I see in ManagedCursorImpl that this case should be handled well.
https://github.com/apache/pulsar/blob/76d3426b72a79ee9f8812fa66e45239830ff1c80/managed-ledger/src/main/java/org/apache/bookkeeper/mledger/impl/ManagedCursorImpl.java#L647
**To Reproduce**
I do not have an easy way to reproduce this problem.
Currently it happens while running the JMS TCK against the Pulsar JMS client
using Pulsar 2.8.0 server.
I have seen that the system is in this messed situation after running the
part of TCK about "transactions".
But I am able to reproduce the problem consistently.
**Expected behavior**
peekMessages should return the next message that is to be read by the
subscription.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
