activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Parker McClure (Issue Comment Edited) (JIRA)" <jira+amq...@apache.org>
Subject [jira] [Issue Comment Edited] (AMQNET-358) Why do ActiveMQ Consumers Recover to Pull Mode instead of Prefetch
Date Thu, 22 Dec 2011 13:30:31 GMT

    [ https://issues.apache.org/jira/browse/AMQNET-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13174798#comment-13174798
] 

Jonathan Parker McClure edited comment on AMQNET-358 at 12/22/11 1:30 PM:
--------------------------------------------------------------------------

Hi Tim. Please find attached a revised version of the sample app. You will find an additional
project called AMQTestConsumerBare that does not use Spring at all. Just Apache.NMS directly.
I see the exact same behavior. 

Looking at the code in ConnectionStateTracker, I see this condition in DoRestoreConsumer()
that controls the pull v.s push recovery..
                if(!connectionInterruptionProcessingComplete && infoToSend.PrefetchSize
> 0 && transport.WireFormat.Version > 5)

..and it appears this never gets called:

ConnectionInterruptProcessingComplete(..)

I know I must be missing something, but the test case is dirt simple and always fails to recover.

Please let me know what you think I can do. And Thank you for your time.

                
      was (Author: jericosandhorn):
    Hi Tim. Please find attached a revised version of the sample app. You will find an additional
project called AMQTestConsumerBare that does not use Spring at all. Just Apache.NMS directly.
I see the exact same behavior. 

Looking at the code in ConnectionStateTracker, I see this condition that controls the pull
v.s push recovery..
                if(!connectionInterruptionProcessingComplete && infoToSend.PrefetchSize
> 0 && transport.WireFormat.Version > 5)

..and it appears this never gets called:

ConnectionInterruptProcessingComplete(..)

Or perhaps this line in DoRestoreConsumers() 

I know I must be missing something, but the test case is dirt simple and always fails to recover.

Please let me know what you think I can do. And Thank you for your time.

                  
> Why do ActiveMQ Consumers Recover to Pull Mode instead of Prefetch
> ------------------------------------------------------------------
>
>                 Key: AMQNET-358
>                 URL: https://issues.apache.org/jira/browse/AMQNET-358
>             Project: ActiveMQ .Net
>          Issue Type: Bug
>          Components: ActiveMQ
>    Affects Versions: 1.5.2
>         Environment: Windows Server 2008 R2 Standard
> AMQ Broker 5.4.2
> Spring.NET 1.3.2
> Apache.NMS 1.5.0
> Apache.NMS.ActiveMQ 1.5.2
>            Reporter: Jonathan Parker McClure
>            Assignee: Timothy Bish
>         Attachments: AMQTestApp.7z, AMQTestAppNoSpring.7z
>
>
> I recently upgraded to NMS ActiveMQ 1.5.2 and when I restart the broker, the connection
and the consumers get restored, but they get restored to the "pull" mode, which means the
broker will not send them messages automatically. This isn't how the previous version behaved.
What I need is for it to recover back to the way it was, which was prefetch 1000. I think
I must be missing a setting for the failover URL or something like that.
> My URL looks like this: 
> failover:(tcp://localhost:61616?consumer.prefetchSize=1266)
> I peaked at the source and it looks like the final "completion" isn't getting to this
area:
> Tracer.Debug("restored recovering consumer: " + control.ConsumerId + " with: " + control.Prefetch);
> Here is the log output from the consumer.
> restore consumer: ID:csi-dul-516m-6334-634583598187658753-1:0:-1:1 in pull mode pending
recovery, overriding prefetch: 1000
> restore consumer: ID:csi-dul-516m-6334-634583598187658753-1:0:-1:1
> restore consumer: ID:csi-dul-516m-6334-634583598187658753-1:0:1:1 in pull mode pending
   
> recovery, overriding prefetch: 1000
> restore consumer: ID:csi-dul-516m-6334-634583598187658753-1:0:1:1
> restore consumer: ID:csi-dul-516m-6334-634583598187658753-1:0:2:1 in pull mode pending
   
> recovery, overriding prefetch: 1000
> restore consumer: ID:csi-dul-516m-6334-634583598187658753-1:0:2:1
> Sending queued commands...
> Transport has resumed normal operation.
> Connection established
> Successfully reconnected to: tcp://localhost:61616/

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message