You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Christian Mamen (JIRA)" <ji...@apache.org> on 2014/05/14 18:31:21 UTC

[jira] [Created] (AMQCPP-543) message producer send never blocking when using producer flow control

Christian Mamen created AMQCPP-543:
--------------------------------------

             Summary: message producer send never blocking when using producer flow control
                 Key: AMQCPP-543
                 URL: https://issues.apache.org/jira/browse/AMQCPP-543
             Project: ActiveMQ C++ Client
          Issue Type: Bug
    Affects Versions: 3.8.2
            Reporter: Christian Mamen
            Assignee: Timothy Bish


For testing, 
message producer is set to non-persisted mode, with the connection producer window size to 1MB. (the broker enables the producer flow control and set the memory limit to ~10MB with vm only storage)

I notice that when i don't have any message consumer, the broker notify me that the memory limit is reached, that the producer will be throttled (as i would expect), however the producer never blocks on a send, as if the window size has no effect.

while digging into ActiveMQProducerKernel.cpp,
I notice the private member memoryUsage (auto_ptr) is never initialized. and there's a TODO in the code ?
{code}
ActiveMQProducerKernel::ActiveMQProducerKernel(

[...]

    // TODO - Check for need of MemoryUsage if there's a producer Windows size
    //        and the Protocol version is greater than 3.
}
{code}

I tried initializing the memoryUsage, and producer seem to block as expected on a send, when the limit is reached.
{code}
ActiveMQProducerKernel::ActiveMQProducerKernel(

[...]

    // TODO - Check for need of MemoryUsage if there's a producer Windows size
    //        and the Protocol version is greater than 3.

    if (session->getConnection()->getProducerWindowSize()) { 
            this->memoryUsage.reset( new MemoryUsage(session->getConnection()->getProducerWindowSize()) );
    }
}
{code}

I'm not sure what is the proper fix,









--
This message was sent by Atlassian JIRA
(v6.2#6252)