Paging may be disruptted in some case ------------------------------------- Key: JBMESSAGING-1778 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1778 Project: JBoss Messaging Issue Type: Bug Components: Messaging Core Affects Versions: 1.4.6.GA, 1.4.5.GA, 1.4.0.SP3.CP09 Reporter: Howard Gao Assignee: Howard Gao Fix For: 1.4.0.SP3.CP10, 1.4.6.GA.SP1, 1.4.7.GA The following test scenario is used to produce the issues: A queue (named testQ) with fullSize = 200, downCacheSize = pageSize = 100. A producer keeps sending messages to testQ. A consumer is created on it but it doesn't actually receive any messages. After each message has been sent, the connection on which the producer and consumer are created is closed, and a new connection is created for next message (therefore a new producer and new consumer). See attachment for the test code. The test creates such a scenario where messages are continuously sent to the queue and the queue continuously delivers message out to the consumer. And because the consumer closing each time so messages (prefetched) are continuously cancelled back to the queue. Messages are continuously accumulated at the queue and will eventually pass the fullSize, triggering paging. That's when the error may happen. case 1. Paging order may go negative This can happen if the following sequence happens: 1. The 200th message arrives at the queue, now the queue reaches fullSize, paging is set to true (firstPagingOrder = nextPagingOrder = 0) 2. The 201th message arrives at the queue, it will be paged to the downCache. (firstPagingOrder = 0, nextPagingOrder = 1) 3. The queue delivers out a message, so the 201th message is loaded from downCache to memory. (firstPagingOrder = nextPagingOrder = 0) Note the paging is still true at the moment, queue size = 200. 4. A message is cancelled back to queue. Because now the queue size is 201, it will move the last one down to cache. Because this is cancelling, the firstPagingOrder will be decreased. So firstPagingOrder = -1. case 2. Paging may be missed This can happen if the following sequence happens: 1. The 200th message arrives at the queue, now the queue reaches fullSize, paging is set to true (firstPagingOrder = nextPagingOrder = 0) 2. The queue delivers n messages and the exact n messages are cancelled back to queue. The delivering makes the queue size shrink and as a result switches the queue to non-paging mode. While the cancelling makes the queue size increase up to fullSize again, but it doesn't change the paging state. Therefore, after that event, the queue reaches fullSize but the paging is false. 3. The 201th message arrives at the queue, making the queue size 201. Because we check the paging using the following condition: if (messageRefs.size() == fullSize) paging = true; (see PagingChannelSupport.addReferenceInMemory()). So the paging will never be turned on as we have already passed the right condition! Case 1 may not be a problem as the distance between firstPagingOrder and nextPagingOrder remains correct. Case 2 is a serious issue as it makes page settings useless. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira