Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Message-ID: <683537072.1206398732696.JavaMail.jira@brutus>
Date: Mon, 24 Mar 2008 15:45:32 -0700 (PDT)
From: "David Jencks (JIRA)" <jira@apache.org>
To: dev@activemq.apache.org
Subject: [jira] Commented: (AMQ-1632) PrefetchSubscription may not wake up
 if messages delivered in transaction
In-Reply-To: <84853990.1206340232654.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/activemq/browse/AMQ-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=41769#action_41769 ] 

David Jencks commented on AMQ-1632:
-----------------------------------

I talked with Hiram a bit and we decided that the real problem was that prefetchSize was being calculated wrong.  MDBs instances for an activation spec all share a single multithreaded consumer.  So the prefetch size ought to be maxMessagesPerSession * maxSessions, so each mdb gets a chance at maxMessagesPerSession.  Previously prefetchSize = maxMessagesPerSession which resulted in some mdbs never getting a chance to process anything if maxMessagesPerSession < maxSessions.

Still haven't looked at trunk.

> PrefetchSubscription may not wake up if messages delivered in transaction
> -------------------------------------------------------------------------
>
>                 Key: AMQ-1632
>                 URL: https://issues.apache.org/activemq/browse/AMQ-1632
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 4.1.1
>            Reporter: David Jencks
>            Assignee: David Jencks
>             Fix For: 4.1.2
>
>
> we noticed mdbs w/transaction on don't work if the prefetch size is less than the number of sessions for the mdb.  There's an error in calculating the prefetchExtension in afterCommit and there's no notification that it might be time to send more messages.  Apparently if the prefetch size is large enough one of the earlier acks triggers delivery of the next batch.
> There are also a bunch of synchronization errors in some classes...

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.