[jira] [Updated] (AMQ-4621) Provide a polling SlowConsumerPolicy that uses LastAck time on a sub

[Jason Shepherd (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-4621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jason Shepherd updated AMQ-4621:


Attachment: AMQFreezeTest-5.8.0.redhat-60029.zip

Another test should be fixed by this issue.

> Provide a polling SlowConsumerPolicy that uses LastAck time on a sub
> 
>
> Key: AMQ-4621
> URL: https://issues.apache.org/jira/browse/AMQ-4621
> Project: ActiveMQ
>  Issue Type: Improvement
>Affects Versions: 5.8.0
>Reporter: Gary Tully
>Assignee: Timothy Bish
>  Labels: abort, connection, consumer, policy, slowConsumers
> Fix For: 5.9.0
>
> Attachments: AMQ4621Patch.txt, AMQFreezeTest-5.8.0.redhat-60029.zip, 
> kahaPendingMEssage-20130905.zip, kahaPendingMEssage-20130906.zip
>
>
> The existing AbortSlowConsumer policy is event driven. It depends on a 
> consumer slow event that is triggered when the prefetch is reached and there 
> are subsequent dispatches.
> With prefetch=0|1 there still needs to be throughput to determine that the 
> consumer is slow so one message can be pending if there are no new messages 
> to sent to the destination.
> Providing an alternative implementation that will periodically poll consumers 
> for their last ack time will be more deterministic. The slow advisory may 
> never fire, but the consumer will get aborted if it does not ack in a timely 
> manner.
> if lastAckTime exceeds the max and there are dispatched messages it can be a 
> candidate for removal.
> Optionally lastAckTime exceeding and no dispatched messages can be a way to 
> remove idle consumers. Not sure if that is necessary.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (AMQ-4621) Provide a polling SlowConsumerPolicy that uses LastAck time on a sub

[Jason Shepherd (JIRA)]

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

Jason Shepherd commented on AMQ-4621:
-

Should we reopen this issue? Tim mentioned to me via email he made some 
adjustments to the fix for this issue, but I can't find them in the Apache 
ActiveMQ repo, git://git.apache.org/activemq.git.



> Provide a polling SlowConsumerPolicy that uses LastAck time on a sub
> 
>
> Key: AMQ-4621
> URL: https://issues.apache.org/jira/browse/AMQ-4621
> Project: ActiveMQ
>  Issue Type: Improvement
>Affects Versions: 5.8.0
>Reporter: Gary Tully
>Assignee: Timothy Bish
>  Labels: abort, connection, consumer, policy, slowConsumers
> Fix For: 5.9.0
>
> Attachments: AMQ4621Patch.txt, kahaPendingMEssage-20130905.zip, 
> kahaPendingMEssage-20130906.zip
>
>
> The existing AbortSlowConsumer policy is event driven. It depends on a 
> consumer slow event that is triggered when the prefetch is reached and there 
> are subsequent dispatches.
> With prefetch=0|1 there still needs to be throughput to determine that the 
> consumer is slow so one message can be pending if there are no new messages 
> to sent to the destination.
> Providing an alternative implementation that will periodically poll consumers 
> for their last ack time will be more deterministic. The slow advisory may 
> never fire, but the consumer will get aborted if it does not ack in a timely 
> manner.
> if lastAckTime exceeds the max and there are dispatched messages it can be a 
> candidate for removal.
> Optionally lastAckTime exceeding and no dispatched messages can be a way to 
> remove idle consumers. Not sure if that is necessary.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (AMQ-4715) Memory issue with ActiveMQ in java

[Timothy Bish (JIRA)]

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

Timothy Bish commented on AMQ-4715:
---

GC is a lazy process and there's nothing that requires it to run during this 
code if it doesn't get to a point where it's really needed.  

> Memory issue with ActiveMQ in java
> --
>
> Key: AMQ-4715
> URL: https://issues.apache.org/jira/browse/AMQ-4715
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 5.6.0, 5.7.0
>Reporter: ritesh
>
> Every time when i start connection and create session i can see “java.exe” 
> (in task manger) memory get increase by 1000 to 2000K that’s ok.
> Now, when i closed connection and session expecting to memory  go down by 
> 1000 to 2000K but nothing happening.
> Here is my sample code.
> {code}
> public static void main(String[] args)
> {
>   try
>   {
> ActiveMQConnectionFactory connectionFactory = new 
> ActiveMQConnectionFactory("tcp://localhost:61616");
> Connection connection= connectionFactory.createConnection();
> connection.start();  
> for(int i=0;i<40;i++)
> {
> Session   session=  m_connection.createSession(false, 
> Session.CLIENT_ACKNOWLEDGE);
> Destination queueDestination = session.createQueue("TestQueue");
> MessageProducer producer = session.createProducer(queueDestination);
> producer.setDeliveryMode(DeliveryMode.NON_PERSISTENT);
> TextMessage   textMessage = session.createTextMessage();
> textMessage.setText(“some text”);
> String jmsCorrelationId= UUID.randomUUID().toString();
> textMessage.setJMSCorrelationID(m_jmsCorrelationId);
> producer.send(textMessage);
> if(!producer.equals(null))
> {
> producer.close();
>  producer=null;
> }
> if(!m_session.equals(null))
> {
> session.close();
> ession=null;
> }
> } // end for loop
> if(connection!=null)
> {
>   connection.close();
> }
>  }
> {code}
> If you will execute this program three to four times you will see significant 
> memory get increase in task manger for “java.exe”.
> Thing most bothering me is that… after executing this program all allocated 
> memory should get cleaned-up by GC but look like somehow it’s not happening.
> No idea what am I doing wrong?
> Please help me!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (AMQ-4715) Memory issue with ActiveMQ in java

[Timothy Bish (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-4715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothy Bish updated AMQ-4715:
--

Description: 
Every time when i start connection and create session i can see “java.exe” (in 
task manger) memory get increase by 1000 to 2000K that’s ok.
Now, when i closed connection and session expecting to memory  go down by 1000 
to 2000K but nothing happening.

Here is my sample code.

{code}
public static void main(String[] args)
{
  try
  {
ActiveMQConnectionFactory connectionFactory = new 
ActiveMQConnectionFactory("tcp://localhost:61616");
Connection connection= connectionFactory.createConnection();
connection.start();  


for(int i=0;i<40;i++)
{


Session session=  m_connection.createSession(false, Session.CLIENT_ACKNOWLEDGE);

Destination queueDestination = session.createQueue("TestQueue");

MessageProducer producer = session.createProducer(queueDestination);
producer.setDeliveryMode(DeliveryMode.NON_PERSISTENT);

TextMessage textMessage = session.createTextMessage();
textMessage.setText(“some text”);

String jmsCorrelationId= UUID.randomUUID().toString();
textMessage.setJMSCorrelationID(m_jmsCorrelationId);

producer.send(textMessage);

if(!producer.equals(null))
{
producer.close();
 producer=null;
}
if(!m_session.equals(null))
{
session.close();
ession=null;
}


} // end for loop

if(connection!=null)
{
  connection.close();

}
 }
{code}

If you will execute this program three to four times you will see significant 
memory get increase in task manger for “java.exe”.
Thing most bothering me is that… after executing this program all allocated 
memory should get cleaned-up by GC but look like somehow it’s not happening.

No idea what am I doing wrong?

Please help me!


  was:
Every time when i start connection and create session i can see “java.exe” (in 
task manger) memory get increase by 1000 to 2000K that’s ok.
Now, when i closed connection and session expecting to memory  go down by 1000 
to 2000K but nothing happening.

Here is my sample code.

public static void main(String[] args)
{
  try
  {
ActiveMQConnectionFactory connectionFactory = new 
ActiveMQConnectionFactory("tcp://localhost:61616");
Connection connection= connectionFactory.createConnection();
connection.start();  


for(int i=0;i<40;i++)
{


Session session=  m_connection.createSession(false, Session.CLIENT_ACKNOWLEDGE);

Destination queueDestination = session.createQueue("TestQueue");

MessageProducer producer = session.createProducer(queueDestination);
producer.setDeliveryMode(DeliveryMode.NON_PERSISTENT);

TextMessage textMessage = session.createTextMessage();
textMessage.setText(“some text”);

String jmsCorrelationId= UUID.randomUUID().toString();
textMessage.setJMSCorrelationID(m_jmsCorrelationId);

producer.send(textMessage);

if(!producer.equals(null))
{
producer.close();
 producer=null;
}
if(!m_session.equals(null))
{
session.close();
ession=null;
}


} // end for loop

if(connection!=null)
{
  connection.close();

}
 }

If you will execute this program three to four times you will see significant 
memory get increase in task manger for “java.exe”.
Thing most bothering me is that… after executing this program all allocated 
memory should get cleaned-up by GC but look like somehow it’s not happening.

No idea what am I doing wrong?

Please help me!



> Memory issue with ActiveMQ in java
> --
>
> Key: AMQ-4715
> URL: https://issues.apache.org/jira/browse/AMQ-4715
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 5.6.0, 5.7.0
>Reporter: ritesh
>
> Every time when i start connection and create session i can see “java.exe” 
> (in task manger) memory get increase by 1000 to 2000K that’s ok.
> Now, when i closed connection and session expecting to memory  go down by 
> 1000 to 2000K but nothing happening.
> Here is my sample code.
> {code}
> public static void main(String[] args)
> {
>   try
>   {
> ActiveMQConnectionFactory connectionFactory = new 
> ActiveMQConnectionFactory("tcp://localhost:61616");
> Connection connection= connectionFactory.createConnection();
> connection.start();  
> for(int i=0;i<40;i++)
> {
> Session   session=  m_connection.createSession(false, 
> Session.CLIENT_ACKNOWLEDGE);
> Destination queueDestination = session.createQueue("TestQueue");
> MessageProducer producer = session.createProducer(queueDestination);
> producer.setDeliveryMode(DeliveryMode.NON_PERSISTENT);
> TextMessage   textMessage = session.createTextMessage();
> textMessage.setText(“some text”);
> String jmsCorrelationId= UUID.randomUUID().toString();
> textMessage.setJMSCorrelationID(m_jmsCorrelationId);
> producer.send(textMessage);
> if(!producer.equals(null))
> {

[jira] [Updated] (AMQ-4715) Memory issue with ActiveMQ in java

[ritesh (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-4715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ritesh updated AMQ-4715:


Description: 
Every time when i start connection and create session i can see “java.exe” (in 
task manger) memory get increase by 1000 to 2000K that’s ok.
Now, when i closed connection and session expecting to memory  go down by 1000 
to 2000K but nothing happening.

Here is my sample code.

public static void main(String[] args)
{
  try
  {
ActiveMQConnectionFactory connectionFactory = new 
ActiveMQConnectionFactory("tcp://localhost:61616");
Connection connection= connectionFactory.createConnection();
connection.start();  


for(int i=0;i<40;i++)
{


Session session=  m_connection.createSession(false, Session.CLIENT_ACKNOWLEDGE);

Destination queueDestination = session.createQueue("TestQueue");

MessageProducer producer = session.createProducer(queueDestination);
producer.setDeliveryMode(DeliveryMode.NON_PERSISTENT);

TextMessage textMessage = session.createTextMessage();
textMessage.setText(“some text”);

String jmsCorrelationId= UUID.randomUUID().toString();
textMessage.setJMSCorrelationID(m_jmsCorrelationId);

producer.send(textMessage);

if(!producer.equals(null))
{
producer.close();
 producer=null;
}
if(!m_session.equals(null))
{
session.close();
ession=null;
}


} // end for loop

if(connection!=null)
{
  connection.close();

}
 }

If you will execute this program three to four times you will see significant 
memory get increase in task manger for “java.exe”.
Thing most bothering me is that… after executing this program all allocated 
memory should get cleaned-up by GC but look like somehow it’s not happening.

No idea what am I doing wrong?

Please help me!


  was:
Every time when i start connection and create session i can see “java.exe” (in 
task manger) memory get increase by 1000 to 2000K that’s ok.
Now, when i closed connection and session expecting to memory  go down by 1000 
to 2000K but nothing happening.

Here is my sample code.

public static void main(String[] args)
{
  try
  {
ActiveMQConnectionFactory connectionFactory = new 
ActiveMQConnectionFactory("tcp://localhost:61616");
Connection connection= connectionFactory.createConnection();
connection.start();  


for(int i=0;i<40;i++)
{


Session session=  m_connection.createSession(false, Session.CLIENT_ACKNOWLEDGE);

Destination queueDestination = session.createQueue("TestQueue");

MessageProducer producer = session.createProducer(queueDestination);
producer.setDeliveryMode(DeliveryMode.NON_PERSISTENT);

TextMessage textMessage = session.createTextMessage();
textMessage.setText(“some text”);

String jmsCorrelationId= UUID.randomUUID().toString();
textMessage.setJMSCorrelationID(m_jmsCorrelationId);

producer.send(textMessage);

if(!producer.equals(null))
{
producer.close();
 producer=null;
}
if(!m_session.equals(null))
{
session.close();
ession=null;
}


} // end for loop

if(connection!=null)
{
  connection.close();

}
 }

If you will execute this program three to four time you will see significant 
memory get increase in task manger for “java.exe”.
Thing most bothering me is that… after executing this program all allocated 
memory should get cleaned-up by GC but look like somehow it’s not happening.

No idea what am I doing wrong?

Please help me!



> Memory issue with ActiveMQ in java
> --
>
> Key: AMQ-4715
> URL: https://issues.apache.org/jira/browse/AMQ-4715
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 5.6.0, 5.7.0
>Reporter: ritesh
>
> Every time when i start connection and create session i can see “java.exe” 
> (in task manger) memory get increase by 1000 to 2000K that’s ok.
> Now, when i closed connection and session expecting to memory  go down by 
> 1000 to 2000K but nothing happening.
> Here is my sample code.
> public static void main(String[] args)
> {
>   try
>   {
> ActiveMQConnectionFactory connectionFactory = new 
> ActiveMQConnectionFactory("tcp://localhost:61616");
> Connection connection= connectionFactory.createConnection();
> connection.start();  
> for(int i=0;i<40;i++)
> {
> Session   session=  m_connection.createSession(false, 
> Session.CLIENT_ACKNOWLEDGE);
> Destination queueDestination = session.createQueue("TestQueue");
> MessageProducer producer = session.createProducer(queueDestination);
> producer.setDeliveryMode(DeliveryMode.NON_PERSISTENT);
> TextMessage   textMessage = session.createTextMessage();
> textMessage.setText(“some text”);
> String jmsCorrelationId= UUID.randomUUID().toString();
> textMessage.setJMSCorrelationID(m_jmsCorrelationId);
> producer.send(textMessage);
> if(!producer.equals(null))
> {
> producer.close();
>  

[jira] [Created] (AMQ-4715) Memory issue with ActiveMQ in java

[ritesh (JIRA)]

ritesh created AMQ-4715:
---

 Summary: Memory issue with ActiveMQ in java
 Key: AMQ-4715
 URL: https://issues.apache.org/jira/browse/AMQ-4715
 Project: ActiveMQ
  Issue Type: Bug
Affects Versions: 5.7.0, 5.6.0
Reporter: ritesh


Every time when i start connection and create session i can see “java.exe” (in 
task manger) memory get increase by 1000 to 2000K that’s ok.
Now, when i closed connection and session expecting to memory  go down by 1000 
to 2000K but nothing happening.

Here is my sample code.

public static void main(String[] args)
{
  try
  {
ActiveMQConnectionFactory connectionFactory = new 
ActiveMQConnectionFactory("tcp://localhost:61616");
Connection connection= connectionFactory.createConnection();
connection.start();  


for(int i=0;i<40;i++)
{


Session session=  m_connection.createSession(false, Session.CLIENT_ACKNOWLEDGE);

Destination queueDestination = session.createQueue("TestQueue");

MessageProducer producer = session.createProducer(queueDestination);
producer.setDeliveryMode(DeliveryMode.NON_PERSISTENT);

TextMessage textMessage = session.createTextMessage();
textMessage.setText(“some text”);

String jmsCorrelationId= UUID.randomUUID().toString();
textMessage.setJMSCorrelationID(m_jmsCorrelationId);

producer.send(textMessage);

if(!producer.equals(null))
{
producer.close();
 producer=null;
}
if(!m_session.equals(null))
{
session.close();
ession=null;
}


} // end for loop

if(connection!=null)
{
  connection.close();

}
 }

If you will execute this program three to four time you will see significant 
memory get increase in task manger for “java.exe”.
Thing most bothering me is that… after executing this program all allocated 
memory should get cleaned-up by GC but look like somehow it’s not happening.

No idea what am I doing wrong?

Please help me!


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (AMQ-4715) Memory issue with ActiveMQ in java

[Timothy Bish (JIRA)]

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

Timothy Bish commented on AMQ-4715:
---

There's not much we can do to help you here, you can post logs related to the 
out of memory error but without more to go on it doesn't sound like an ActiveMQ 
problem. 

> Memory issue with ActiveMQ in java
> --
>
> Key: AMQ-4715
> URL: https://issues.apache.org/jira/browse/AMQ-4715
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 5.6.0, 5.7.0
>Reporter: ritesh
>
> Every time when i start connection and create session i can see “java.exe” 
> (in task manger) memory get increase by 1000 to 2000K that’s ok.
> Now, when i closed connection and session expecting to memory  go down by 
> 1000 to 2000K but nothing happening.
> Here is my sample code.
> {code}
> public static void main(String[] args)
> {
>   try
>   {
> ActiveMQConnectionFactory connectionFactory = new 
> ActiveMQConnectionFactory("tcp://localhost:61616");
> Connection connection= connectionFactory.createConnection();
> connection.start();  
> for(int i=0;i<40;i++)
> {
> Session   session=  m_connection.createSession(false, 
> Session.CLIENT_ACKNOWLEDGE);
> Destination queueDestination = session.createQueue("TestQueue");
> MessageProducer producer = session.createProducer(queueDestination);
> producer.setDeliveryMode(DeliveryMode.NON_PERSISTENT);
> TextMessage   textMessage = session.createTextMessage();
> textMessage.setText(“some text”);
> String jmsCorrelationId= UUID.randomUUID().toString();
> textMessage.setJMSCorrelationID(m_jmsCorrelationId);
> producer.send(textMessage);
> if(!producer.equals(null))
> {
> producer.close();
>  producer=null;
> }
> if(!m_session.equals(null))
> {
> session.close();
> ession=null;
> }
> } // end for loop
> if(connection!=null)
> {
>   connection.close();
> }
>  }
> {code}
> If you will execute this program three to four times you will see significant 
> memory get increase in task manger for “java.exe”.
> Thing most bothering me is that… after executing this program all allocated 
> memory should get cleaned-up by GC but look like somehow it’s not happening.
> No idea what am I doing wrong?
> Please help me!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (AMQ-4715) Memory issue with ActiveMQ in java

[ritesh (JIRA)]

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

ritesh commented on AMQ-4715:
-

you get it wrong, i m not blaiming asking for a help!

> Memory issue with ActiveMQ in java
> --
>
> Key: AMQ-4715
> URL: https://issues.apache.org/jira/browse/AMQ-4715
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 5.6.0, 5.7.0
>Reporter: ritesh
>
> Every time when i start connection and create session i can see “java.exe” 
> (in task manger) memory get increase by 1000 to 2000K that’s ok.
> Now, when i closed connection and session expecting to memory  go down by 
> 1000 to 2000K but nothing happening.
> Here is my sample code.
> {code}
> public static void main(String[] args)
> {
>   try
>   {
> ActiveMQConnectionFactory connectionFactory = new 
> ActiveMQConnectionFactory("tcp://localhost:61616");
> Connection connection= connectionFactory.createConnection();
> connection.start();  
> for(int i=0;i<40;i++)
> {
> Session   session=  m_connection.createSession(false, 
> Session.CLIENT_ACKNOWLEDGE);
> Destination queueDestination = session.createQueue("TestQueue");
> MessageProducer producer = session.createProducer(queueDestination);
> producer.setDeliveryMode(DeliveryMode.NON_PERSISTENT);
> TextMessage   textMessage = session.createTextMessage();
> textMessage.setText(“some text”);
> String jmsCorrelationId= UUID.randomUUID().toString();
> textMessage.setJMSCorrelationID(m_jmsCorrelationId);
> producer.send(textMessage);
> if(!producer.equals(null))
> {
> producer.close();
>  producer=null;
> }
> if(!m_session.equals(null))
> {
> session.close();
> ession=null;
> }
> } // end for loop
> if(connection!=null)
> {
>   connection.close();
> }
>  }
> {code}
> If you will execute this program three to four times you will see significant 
> memory get increase in task manger for “java.exe”.
> Thing most bothering me is that… after executing this program all allocated 
> memory should get cleaned-up by GC but look like somehow it’s not happening.
> No idea what am I doing wrong?
> Please help me!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (AMQ-4715) Memory issue with ActiveMQ in java

[Timothy Bish (JIRA)]

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

Timothy Bish commented on AMQ-4715:
---

You'd need to do more analysis on your code / app before blaiming activemq, use 
a tool like yourkit to look at the usage of you app.  

> Memory issue with ActiveMQ in java
> --
>
> Key: AMQ-4715
> URL: https://issues.apache.org/jira/browse/AMQ-4715
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 5.6.0, 5.7.0
>Reporter: ritesh
>
> Every time when i start connection and create session i can see “java.exe” 
> (in task manger) memory get increase by 1000 to 2000K that’s ok.
> Now, when i closed connection and session expecting to memory  go down by 
> 1000 to 2000K but nothing happening.
> Here is my sample code.
> {code}
> public static void main(String[] args)
> {
>   try
>   {
> ActiveMQConnectionFactory connectionFactory = new 
> ActiveMQConnectionFactory("tcp://localhost:61616");
> Connection connection= connectionFactory.createConnection();
> connection.start();  
> for(int i=0;i<40;i++)
> {
> Session   session=  m_connection.createSession(false, 
> Session.CLIENT_ACKNOWLEDGE);
> Destination queueDestination = session.createQueue("TestQueue");
> MessageProducer producer = session.createProducer(queueDestination);
> producer.setDeliveryMode(DeliveryMode.NON_PERSISTENT);
> TextMessage   textMessage = session.createTextMessage();
> textMessage.setText(“some text”);
> String jmsCorrelationId= UUID.randomUUID().toString();
> textMessage.setJMSCorrelationID(m_jmsCorrelationId);
> producer.send(textMessage);
> if(!producer.equals(null))
> {
> producer.close();
>  producer=null;
> }
> if(!m_session.equals(null))
> {
> session.close();
> ession=null;
> }
> } // end for loop
> if(connection!=null)
> {
>   connection.close();
> }
>  }
> {code}
> If you will execute this program three to four times you will see significant 
> memory get increase in task manger for “java.exe”.
> Thing most bothering me is that… after executing this program all allocated 
> memory should get cleaned-up by GC but look like somehow it’s not happening.
> No idea what am I doing wrong?
> Please help me!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (AMQ-4715) Memory issue with ActiveMQ in java

[Timothy Bish (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-4715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothy Bish updated AMQ-4715:
--

Description: 
Every time when i start connection and create session i can see “java.exe” (in 
task manger) memory get increase by 1000 to 2000K that’s ok.
Now, when i closed connection and session expecting to memory  go down by 1000 
to 2000K but nothing happening.

Here is my sample code.

{code}
public static void main(String[] args) {

  try {
ActiveMQConnectionFactory connectionFactory = new 
ActiveMQConnectionFactory("tcp://localhost:61616");
Connection connection= connectionFactory.createConnection();
connection.start();  

for(int i=0;i<40;i++) {
  Session session=  m_connection.createSession(false, 
Session.CLIENT_ACKNOWLEDGE);
  Destination queueDestination = session.createQueue("TestQueue");

  MessageProducer producer = session.createProducer(queueDestination);
  producer.setDeliveryMode(DeliveryMode.NON_PERSISTENT);

  TextMessage textMessage = session.createTextMessage();
  textMessage.setText(“some text”);

  String jmsCorrelationId= UUID.randomUUID().toString();
  textMessage.setJMSCorrelationID(m_jmsCorrelationId);
  producer.send(textMessage);

  if (producer != null) {
 producer.close();
 producer=null;
  }
  
  if(m_session != null) {
session.close();
session=null;
  }
} // end for loop

if (connection!=null) {
  connection.close();
}
  }
}
{code}

If you will execute this program three to four times you will see significant 
memory get increase in task manger for “java.exe”.
Thing most bothering me is that… after executing this program all allocated 
memory should get cleaned-up by GC but look like somehow it’s not happening.

No idea what am I doing wrong?

Please help me!


  was:
Every time when i start connection and create session i can see “java.exe” (in 
task manger) memory get increase by 1000 to 2000K that’s ok.
Now, when i closed connection and session expecting to memory  go down by 1000 
to 2000K but nothing happening.

Here is my sample code.

{code}
public static void main(String[] args)
{
  try
  {
ActiveMQConnectionFactory connectionFactory = new 
ActiveMQConnectionFactory("tcp://localhost:61616");
Connection connection= connectionFactory.createConnection();
connection.start();  


for(int i=0;i<40;i++)
{


Session session=  m_connection.createSession(false, Session.CLIENT_ACKNOWLEDGE);

Destination queueDestination = session.createQueue("TestQueue");

MessageProducer producer = session.createProducer(queueDestination);
producer.setDeliveryMode(DeliveryMode.NON_PERSISTENT);

TextMessage textMessage = session.createTextMessage();
textMessage.setText(“some text”);

String jmsCorrelationId= UUID.randomUUID().toString();
textMessage.setJMSCorrelationID(m_jmsCorrelationId);

producer.send(textMessage);

if(!producer.equals(null))
{
producer.close();
 producer=null;
}
if(!m_session.equals(null))
{
session.close();
ession=null;
}


} // end for loop

if(connection!=null)
{
  connection.close();

}
 }
{code}

If you will execute this program three to four times you will see significant 
memory get increase in task manger for “java.exe”.
Thing most bothering me is that… after executing this program all allocated 
memory should get cleaned-up by GC but look like somehow it’s not happening.

No idea what am I doing wrong?

Please help me!



> Memory issue with ActiveMQ in java
> --
>
> Key: AMQ-4715
> URL: https://issues.apache.org/jira/browse/AMQ-4715
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 5.6.0, 5.7.0
>Reporter: ritesh
>
> Every time when i start connection and create session i can see “java.exe” 
> (in task manger) memory get increase by 1000 to 2000K that’s ok.
> Now, when i closed connection and session expecting to memory  go down by 
> 1000 to 2000K but nothing happening.
> Here is my sample code.
> {code}
> public static void main(String[] args) {
>   try {
> ActiveMQConnectionFactory connectionFactory = new 
> ActiveMQConnectionFactory("tcp://localhost:61616");
> Connection connection= connectionFactory.createConnection();
> connection.start();  
> for(int i=0;i<40;i++) {
>   Session session=  m_connection.createSession(false, 
> Session.CLIENT_ACKNOWLEDGE);
>   Destination queueDestination = session.createQueue("TestQueue");
>   MessageProducer producer = session.createProducer(queueDestination);
>   producer.setDeliveryMode(DeliveryMode.NON_PERSISTENT);
>   TextMessage textMessage = session.createTextMessage();
>   textMessage.setText(“some text”);
>   String jmsCorrelationId= UUID.randomUUID().toString();
>

[jira] [Commented] (AMQ-4715) Memory issue with ActiveMQ in java

[ritesh (JIRA)]

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

ritesh commented on AMQ-4715:
-

That was my test app. but in my real app we do running out of memory 

> Memory issue with ActiveMQ in java
> --
>
> Key: AMQ-4715
> URL: https://issues.apache.org/jira/browse/AMQ-4715
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 5.6.0, 5.7.0
>Reporter: ritesh
>
> Every time when i start connection and create session i can see “java.exe” 
> (in task manger) memory get increase by 1000 to 2000K that’s ok.
> Now, when i closed connection and session expecting to memory  go down by 
> 1000 to 2000K but nothing happening.
> Here is my sample code.
> {code}
> public static void main(String[] args)
> {
>   try
>   {
> ActiveMQConnectionFactory connectionFactory = new 
> ActiveMQConnectionFactory("tcp://localhost:61616");
> Connection connection= connectionFactory.createConnection();
> connection.start();  
> for(int i=0;i<40;i++)
> {
> Session   session=  m_connection.createSession(false, 
> Session.CLIENT_ACKNOWLEDGE);
> Destination queueDestination = session.createQueue("TestQueue");
> MessageProducer producer = session.createProducer(queueDestination);
> producer.setDeliveryMode(DeliveryMode.NON_PERSISTENT);
> TextMessage   textMessage = session.createTextMessage();
> textMessage.setText(“some text”);
> String jmsCorrelationId= UUID.randomUUID().toString();
> textMessage.setJMSCorrelationID(m_jmsCorrelationId);
> producer.send(textMessage);
> if(!producer.equals(null))
> {
> producer.close();
>  producer=null;
> }
> if(!m_session.equals(null))
> {
> session.close();
> ession=null;
> }
> } // end for loop
> if(connection!=null)
> {
>   connection.close();
> }
>  }
> {code}
> If you will execute this program three to four times you will see significant 
> memory get increase in task manger for “java.exe”.
> Thing most bothering me is that… after executing this program all allocated 
> memory should get cleaned-up by GC but look like somehow it’s not happening.
> No idea what am I doing wrong?
> Please help me!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (AMQ-4669) StoreDurableSubscriberCursor cursor is instantiated twice if PendingDurableSubscriberPolicy is explicitly configured, then results in missing TopicStorePrefetch instance

[Timothy Bish (JIRA)]

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

Timothy Bish commented on AMQ-4669:
---

Have you tested a later release.  In the 5.9-SNAPSHOT code there is a test case 
'ConcurrentProducerDurableConsumerTest' which uses this configuration and the 
consumer receives its messages without issue.  

> StoreDurableSubscriberCursor cursor is instantiated twice if 
> PendingDurableSubscriberPolicy is explicitly configured, then results in 
> missing TopicStorePrefetch instance in it.
> 
>
> Key: AMQ-4669
> URL: https://issues.apache.org/jira/browse/AMQ-4669
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.7.0
>Reporter: Jaewoong Choi
>
> If used, PendingDurableSubscriberPolicy is used twice for 
> StoreDurableSubscriberCursor instantiation, meaning 
> StoreDurableSubscriberCursor is instantiated twice: firstly at 
> TopicRegion#createSubscription and secondly at 
> DurableTopicSubscription#activate invocation.
> The critical side effect by the above is that, TopicStorePrefetch (internal 
> PendingMessageCursor for persistent message store) is created/assigned only 
> to the 1st store cursor, and then this 1st store cursor is replaced by the 
> 2nd one.  And this 2nd cursor is used at runtime but without having 
> TopicStorePrefetch cursor, so subscriptions cannot consume any published 
> message.
> Simply, with the following code, topic durable subscribers never consume any 
> published message.
> {code}
> PolicyEntry policyEntry = new PolicyEntry();
> policyEntry.setPendingDurableSubscriberPolicy(new 
> StorePendingDurableSubscriberMessageStoragePolicy());
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Memory leak in activemq-cpp (activemq-cpp-library-3.7.1)

[Timothy Bish]

On 09/09/2013 11:56 AM, sparso wrote:

I'm also seeing this problem. I changed the "example" to send 2,000,000
messages and added a usleep to the producer, and it leaks memory in version
3.7.1 and 3.8.0. Version 3.4.4 does not.

I will attempt to debug the problem (but I'm not familiar with the activemq
code). It does appear to be just the consumer that is leaking memory.



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Memory-leak-in-activemq-cpp-activemq-cpp-library-3-7-1-tp4671248p4671306.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.

Are you sure its a memory leak, or is it just working as it should. 
Depends somewhat on how you are using the client, if you are using 
failover then there is a chance its just the Message Audit and 
Connection State Tracker growing as the consumer is running tracking 
messages to filter duplicates etc.  You should try changing connection 
parameters to narrow it down, otherwise who knows where to start looking.


1. try with and without failover
2. when using failover try turning off message audit.

--
Tim Bish
Sr Software Engineer | RedHat Inc.
tim.b...@redhat.com | www.fusesource.com | www.redhat.com
skype: tabish121 | twitter: @tabish121
blog: http://timbish.blogspot.com/

[jira] [Closed] (AMQ-4669) StoreDurableSubscriberCursor cursor is instantiated twice if PendingDurableSubscriberPolicy is explicitly configured, then results in missing TopicStorePrefetch instance in

[Timothy Bish (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-4669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothy Bish closed AMQ-4669.
-

Resolution: Cannot Reproduce

No test case, existing test 'ConcurrentProducerDurableConsumerTest' seems to 
contradict this issue.  

> StoreDurableSubscriberCursor cursor is instantiated twice if 
> PendingDurableSubscriberPolicy is explicitly configured, then results in 
> missing TopicStorePrefetch instance in it.
> 
>
> Key: AMQ-4669
> URL: https://issues.apache.org/jira/browse/AMQ-4669
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.7.0
>Reporter: Jaewoong Choi
>
> If used, PendingDurableSubscriberPolicy is used twice for 
> StoreDurableSubscriberCursor instantiation, meaning 
> StoreDurableSubscriberCursor is instantiated twice: firstly at 
> TopicRegion#createSubscription and secondly at 
> DurableTopicSubscription#activate invocation.
> The critical side effect by the above is that, TopicStorePrefetch (internal 
> PendingMessageCursor for persistent message store) is created/assigned only 
> to the 1st store cursor, and then this 1st store cursor is replaced by the 
> 2nd one.  And this 2nd cursor is used at runtime but without having 
> TopicStorePrefetch cursor, so subscriptions cannot consume any published 
> message.
> Simply, with the following code, topic durable subscribers never consume any 
> published message.
> {code}
> PolicyEntry policyEntry = new PolicyEntry();
> policyEntry.setPendingDurableSubscriberPolicy(new 
> StorePendingDurableSubscriberMessageStoragePolicy());
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Memory leak in activemq-cpp (activemq-cpp-library-3.7.1)

[sparso]

I'm also seeing this problem. I changed the "example" to send 2,000,000
messages and added a usleep to the producer, and it leaks memory in version
3.7.1 and 3.8.0. Version 3.4.4 does not.

I will attempt to debug the problem (but I'm not familiar with the activemq
code). It does appear to be just the consumer that is leaking memory.



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Memory-leak-in-activemq-cpp-activemq-cpp-library-3-7-1-tp4671248p4671306.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.

[jira] [Commented] (AMQ-4710) The first heart-beat after a connection becomes idle isn't sent as quickly as it should be

[Paul Gale (JIRA)]

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

Paul Gale commented on AMQ-4710:


Just realized I should have used a StompConnection object in the test. Trying 
again.

> The first heart-beat after a connection becomes idle isn't sent as quickly as 
> it should be
> --
>
> Key: AMQ-4710
> URL: https://issues.apache.org/jira/browse/AMQ-4710
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: stomp
>Affects Versions: 5.8.0
>Reporter: Andy Wilkinson
> Attachments: amq-4710.diff
>
>
> After ActiveMQ sends a stomp frame, it may not send a heart-beat for up to 
> almost 2x the negotiated interval.
> The following test should illustrate the problem:
> {code}
> import org.junit.Test;
> import static org.junit.Assert.*;
> public class ActiveMqHeartbeatTests {
>   @Test
>   public void heartbeats() throws Exception {
>   BrokerService broker = createAndStartBroker();
>   Socket socket = null;
>   try {
>   socket = new Socket("localhost", 61613);
>   byte[] connectFrame = 
> "CONNECT\nheart-beat:0,1\naccept-version:1.2\n\n\0".getBytes();
>   socket.getOutputStream().write(connectFrame);
>   byte[] buffer = new byte[4096];
>   long lastReadTime = System.currentTimeMillis();
>   while (true) {
>   int read = socket.getInputStream().read(buffer);
>   byte[] frame = Arrays.copyOf(buffer, read);
>   long now = System.currentTimeMillis();
>   long timeSinceLastRead = now - lastReadTime;
>   lastReadTime = now;
>   System.out.println(new String(frame));
>   System.out.println("Time since last read: " + 
> timeSinceLastRead + "ms");
>   if (timeSinceLastRead > 15000) {
>   fail("Data not received for " + 
> timeSinceLastRead + "ms");
>   }
>   }
>   } finally {
>   if (socket != null) {
>   socket.close();
>   }
>   broker.stop();
>   }
>   }
>   private BrokerService createAndStartBroker() throws Exception {
>   BrokerService broker = new BrokerService();
>   broker.addConnector("stomp://localhost:61613");
>   broker.setStartAsync(false);
>   broker.setDeleteAllMessagesOnStartup(true);
>   broker.start();
>   return broker;
>   }
> }
> {code}
> For the initial read of the CONNECTED frame I see:
> {noformat}
> Time since last read: 49ms
> {noformat}
> However, it's then almost 20 seconds before a heart-beat's sent:
> {noformat}
> Time since last read: 19994ms
> {noformat}
> If I comment out the fail(…) line in the test, after the first heartbeat 
> taking almost 2ms to be sent, things settle down and a heartbeat's 
> received every 1ms.
> It looks like the write checker wakes up every 1ms. The first time it 
> wakes up, it notices that the CONNECTED frame was sent and does nothing. It 
> then sleeps for a further 1ms before checking again. As the CONNECTED 
> frame was sent very early in the first 1ms window, this leads to it 
> taking almost 2ms for the first heart-beat to be sent. From this point, 
> as no further data frames are sent, the write checker wakes up and sends a 
> heart-beat every 1ms.
> In short, I don't think ActiveMQ is adhering to the requirement that "the 
> sender MUST send new data over the network connection at least every  
> milliseconds".

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[ANNOUNCE] ActiveMQ-CPP Version 3.8.0 Released

[Timothy Bish]

Hi Everyone,

Its official, AcitveMQ-CPP v3.8.0 has now been released.

This is a new patch release of ActiveMQ-CPP which contains bug fixes for 
issues that were found since v3.7.1 was released and also some new 
features and build improvements for Windows users.


 * 3.7.0 does not compile with gcc-4.4.7 on CentOS-6
 * APR-Util header include missed in latest release.
 * CMS FailoverTransport Leaks Socket Descriptors
 * closing a connection stalled in start because of failover should
   stop the transport safely.
 * Compilation Error Fix for Sun Studio under Solaris 10
 * Exception lifetime confusion can cause the application to crash
 * Connection didn't switch to the slave broker when the master broker
   is down
 * Commiting a session with a deleted consumer causes access violation
 * Compilation of 3.7.0 fails for Linux systems (Redhat 5.8 and SuSE
   SLES 10)
 * Cient doesn't work on Linux Red Hat 6.4 systems, fails when setting
   thread priority
 * Exception "attempt to unlock read lock, not locked by current
   thread" when doing performance testing
 * For SSL connections ensure the SNI field is set.
 * Can't send to temporary queues created by name
 * Added Visual Studio 2010 project files for the project.
 * Added Destination Source events based listener interfaces to the CMS
   API.

You can download the source package from here:


The complete list of fixes is here:


API documentation for v3.6.0+ versions is located here:


--
Tim Bish
Sr Software Engineer | RedHat Inc.
tim.b...@redhat.com | www.fusesource.com | www.redhat.com
skype: tabish121 | twitter: @tabish121
blog: http://timbish.blogspot.com/

Re: [jira] [Issue Comment Deleted] (AMQ-4710) The first heart-beat after a connection becomes idle isn't sent as quickly as it should be

[Paul Gale]

If any of the ActiveMQ committers could take a look at my patch for this
Jira issue I would really appreciate the feedback as I'd like to
incorporate it into 5.8.0.

Thanks,
Paul


On Mon, Sep 9, 2013 at 10:13 AM, Paul Gale (JIRA)  wrote:

>
>  [
> https://issues.apache.org/jira/browse/AMQ-4710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
>
> Paul Gale updated AMQ-4710:
> ---
>
> Comment: was deleted
>
> (was: Updated patch containing fix for Jira AMQ-4710. Improved the
> checking for when to recreate the write checker timer task. Previous patch
> attachment has been deleted.)
>
> > The first heart-beat after a connection becomes idle isn't sent as
> quickly as it should be
> >
> --
> >
> > Key: AMQ-4710
> > URL: https://issues.apache.org/jira/browse/AMQ-4710
> > Project: ActiveMQ
> >  Issue Type: Bug
> >  Components: stomp
> >Affects Versions: 5.8.0
> >Reporter: Andy Wilkinson
> > Attachments: amq-4710.diff
> >
> >
> > After ActiveMQ sends a stomp frame, it may not send a heart-beat for up
> to almost 2x the negotiated interval.
> > The following test should illustrate the problem:
> > {code}
> > import org.junit.Test;
> > import static org.junit.Assert.*;
> > public class ActiveMqHeartbeatTests {
> >   @Test
> >   public void heartbeats() throws Exception {
> >   BrokerService broker = createAndStartBroker();
> >   Socket socket = null;
> >   try {
> >   socket = new Socket("localhost", 61613);
> >   byte[] connectFrame =
> "CONNECT\nheart-beat:0,1\naccept-version:1.2\n\n\0".getBytes();
> >   socket.getOutputStream().write(connectFrame);
> >   byte[] buffer = new byte[4096];
> >   long lastReadTime = System.currentTimeMillis();
> >   while (true) {
> >   int read =
> socket.getInputStream().read(buffer);
> >   byte[] frame = Arrays.copyOf(buffer, read);
> >   long now = System.currentTimeMillis();
> >   long timeSinceLastRead = now -
> lastReadTime;
> >   lastReadTime = now;
> >   System.out.println(new String(frame));
> >   System.out.println("Time since last read:
> " + timeSinceLastRead + "ms");
> >   if (timeSinceLastRead > 15000) {
> >   fail("Data not received for " +
> timeSinceLastRead + "ms");
> >   }
> >   }
> >   } finally {
> >   if (socket != null) {
> >   socket.close();
> >   }
> >   broker.stop();
> >   }
> >   }
> >   private BrokerService createAndStartBroker() throws Exception {
> >   BrokerService broker = new BrokerService();
> >   broker.addConnector("stomp://localhost:61613");
> >   broker.setStartAsync(false);
> >   broker.setDeleteAllMessagesOnStartup(true);
> >   broker.start();
> >   return broker;
> >   }
> > }
> > {code}
> > For the initial read of the CONNECTED frame I see:
> > {noformat}
> > Time since last read: 49ms
> > {noformat}
> > However, it's then almost 20 seconds before a heart-beat's sent:
> > {noformat}
> > Time since last read: 19994ms
> > {noformat}
> > If I comment out the fail(…) line in the test, after the first heartbeat
> taking almost 2ms to be sent, things settle down and a heartbeat's
> received every 1ms.
> > It looks like the write checker wakes up every 1ms. The first time
> it wakes up, it notices that the CONNECTED frame was sent and does nothing.
> It then sleeps for a further 1ms before checking again. As the
> CONNECTED frame was sent very early in the first 1ms window, this leads
> to it taking almost 2ms for the first heart-beat to be sent. From this
> point, as no further data frames are sent, the write checker wakes up and
> sends a heart-beat every 1ms.
> > In short, I don't think ActiveMQ is adhering to the requirement that
> "the sender MUST send new data over the network connection at least every
>  milliseconds".
>
> --
> This message is automatically generated by JIRA.
> If you think it was sent incorrectly, please contact your JIRA
> administrators
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>

[jira] [Updated] (AMQ-4710) The first heart-beat after a connection becomes idle isn't sent as quickly as it should be

[Paul Gale (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-4710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Gale updated AMQ-4710:
---

Attachment: amq-4710.diff

Unit test and patch to fix this issue.

> The first heart-beat after a connection becomes idle isn't sent as quickly as 
> it should be
> --
>
> Key: AMQ-4710
> URL: https://issues.apache.org/jira/browse/AMQ-4710
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: stomp
>Affects Versions: 5.8.0
>Reporter: Andy Wilkinson
> Attachments: amq-4710.diff
>
>
> After ActiveMQ sends a stomp frame, it may not send a heart-beat for up to 
> almost 2x the negotiated interval.
> The following test should illustrate the problem:
> {code}
> import org.junit.Test;
> import static org.junit.Assert.*;
> public class ActiveMqHeartbeatTests {
>   @Test
>   public void heartbeats() throws Exception {
>   BrokerService broker = createAndStartBroker();
>   Socket socket = null;
>   try {
>   socket = new Socket("localhost", 61613);
>   byte[] connectFrame = 
> "CONNECT\nheart-beat:0,1\naccept-version:1.2\n\n\0".getBytes();
>   socket.getOutputStream().write(connectFrame);
>   byte[] buffer = new byte[4096];
>   long lastReadTime = System.currentTimeMillis();
>   while (true) {
>   int read = socket.getInputStream().read(buffer);
>   byte[] frame = Arrays.copyOf(buffer, read);
>   long now = System.currentTimeMillis();
>   long timeSinceLastRead = now - lastReadTime;
>   lastReadTime = now;
>   System.out.println(new String(frame));
>   System.out.println("Time since last read: " + 
> timeSinceLastRead + "ms");
>   if (timeSinceLastRead > 15000) {
>   fail("Data not received for " + 
> timeSinceLastRead + "ms");
>   }
>   }
>   } finally {
>   if (socket != null) {
>   socket.close();
>   }
>   broker.stop();
>   }
>   }
>   private BrokerService createAndStartBroker() throws Exception {
>   BrokerService broker = new BrokerService();
>   broker.addConnector("stomp://localhost:61613");
>   broker.setStartAsync(false);
>   broker.setDeleteAllMessagesOnStartup(true);
>   broker.start();
>   return broker;
>   }
> }
> {code}
> For the initial read of the CONNECTED frame I see:
> {noformat}
> Time since last read: 49ms
> {noformat}
> However, it's then almost 20 seconds before a heart-beat's sent:
> {noformat}
> Time since last read: 19994ms
> {noformat}
> If I comment out the fail(…) line in the test, after the first heartbeat 
> taking almost 2ms to be sent, things settle down and a heartbeat's 
> received every 1ms.
> It looks like the write checker wakes up every 1ms. The first time it 
> wakes up, it notices that the CONNECTED frame was sent and does nothing. It 
> then sleeps for a further 1ms before checking again. As the CONNECTED 
> frame was sent very early in the first 1ms window, this leads to it 
> taking almost 2ms for the first heart-beat to be sent. From this point, 
> as no further data frames are sent, the write checker wakes up and sends a 
> heart-beat every 1ms.
> In short, I don't think ActiveMQ is adhering to the requirement that "the 
> sender MUST send new data over the network connection at least every  
> milliseconds".

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (AMQ-4710) The first heart-beat after a connection becomes idle isn't sent as quickly as it should be

[Paul Gale (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-4710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Gale updated AMQ-4710:
---

Attachment: (was: amq_4710_2.patch)

> The first heart-beat after a connection becomes idle isn't sent as quickly as 
> it should be
> --
>
> Key: AMQ-4710
> URL: https://issues.apache.org/jira/browse/AMQ-4710
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: stomp
>Affects Versions: 5.8.0
>Reporter: Andy Wilkinson
> Attachments: amq-4710.diff
>
>
> After ActiveMQ sends a stomp frame, it may not send a heart-beat for up to 
> almost 2x the negotiated interval.
> The following test should illustrate the problem:
> {code}
> import org.junit.Test;
> import static org.junit.Assert.*;
> public class ActiveMqHeartbeatTests {
>   @Test
>   public void heartbeats() throws Exception {
>   BrokerService broker = createAndStartBroker();
>   Socket socket = null;
>   try {
>   socket = new Socket("localhost", 61613);
>   byte[] connectFrame = 
> "CONNECT\nheart-beat:0,1\naccept-version:1.2\n\n\0".getBytes();
>   socket.getOutputStream().write(connectFrame);
>   byte[] buffer = new byte[4096];
>   long lastReadTime = System.currentTimeMillis();
>   while (true) {
>   int read = socket.getInputStream().read(buffer);
>   byte[] frame = Arrays.copyOf(buffer, read);
>   long now = System.currentTimeMillis();
>   long timeSinceLastRead = now - lastReadTime;
>   lastReadTime = now;
>   System.out.println(new String(frame));
>   System.out.println("Time since last read: " + 
> timeSinceLastRead + "ms");
>   if (timeSinceLastRead > 15000) {
>   fail("Data not received for " + 
> timeSinceLastRead + "ms");
>   }
>   }
>   } finally {
>   if (socket != null) {
>   socket.close();
>   }
>   broker.stop();
>   }
>   }
>   private BrokerService createAndStartBroker() throws Exception {
>   BrokerService broker = new BrokerService();
>   broker.addConnector("stomp://localhost:61613");
>   broker.setStartAsync(false);
>   broker.setDeleteAllMessagesOnStartup(true);
>   broker.start();
>   return broker;
>   }
> }
> {code}
> For the initial read of the CONNECTED frame I see:
> {noformat}
> Time since last read: 49ms
> {noformat}
> However, it's then almost 20 seconds before a heart-beat's sent:
> {noformat}
> Time since last read: 19994ms
> {noformat}
> If I comment out the fail(…) line in the test, after the first heartbeat 
> taking almost 2ms to be sent, things settle down and a heartbeat's 
> received every 1ms.
> It looks like the write checker wakes up every 1ms. The first time it 
> wakes up, it notices that the CONNECTED frame was sent and does nothing. It 
> then sleeps for a further 1ms before checking again. As the CONNECTED 
> frame was sent very early in the first 1ms window, this leads to it 
> taking almost 2ms for the first heart-beat to be sent. From this point, 
> as no further data frames are sent, the write checker wakes up and sends a 
> heart-beat every 1ms.
> In short, I don't think ActiveMQ is adhering to the requirement that "the 
> sender MUST send new data over the network connection at least every  
> milliseconds".

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Issue Comment Deleted] (AMQ-4710) The first heart-beat after a connection becomes idle isn't sent as quickly as it should be

[Paul Gale (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-4710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Gale updated AMQ-4710:
---

Comment: was deleted

(was: Updated patch containing fix for Jira AMQ-4710. Improved the checking for 
when to recreate the write checker timer task. Previous patch attachment has 
been deleted.)

> The first heart-beat after a connection becomes idle isn't sent as quickly as 
> it should be
> --
>
> Key: AMQ-4710
> URL: https://issues.apache.org/jira/browse/AMQ-4710
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: stomp
>Affects Versions: 5.8.0
>Reporter: Andy Wilkinson
> Attachments: amq-4710.diff
>
>
> After ActiveMQ sends a stomp frame, it may not send a heart-beat for up to 
> almost 2x the negotiated interval.
> The following test should illustrate the problem:
> {code}
> import org.junit.Test;
> import static org.junit.Assert.*;
> public class ActiveMqHeartbeatTests {
>   @Test
>   public void heartbeats() throws Exception {
>   BrokerService broker = createAndStartBroker();
>   Socket socket = null;
>   try {
>   socket = new Socket("localhost", 61613);
>   byte[] connectFrame = 
> "CONNECT\nheart-beat:0,1\naccept-version:1.2\n\n\0".getBytes();
>   socket.getOutputStream().write(connectFrame);
>   byte[] buffer = new byte[4096];
>   long lastReadTime = System.currentTimeMillis();
>   while (true) {
>   int read = socket.getInputStream().read(buffer);
>   byte[] frame = Arrays.copyOf(buffer, read);
>   long now = System.currentTimeMillis();
>   long timeSinceLastRead = now - lastReadTime;
>   lastReadTime = now;
>   System.out.println(new String(frame));
>   System.out.println("Time since last read: " + 
> timeSinceLastRead + "ms");
>   if (timeSinceLastRead > 15000) {
>   fail("Data not received for " + 
> timeSinceLastRead + "ms");
>   }
>   }
>   } finally {
>   if (socket != null) {
>   socket.close();
>   }
>   broker.stop();
>   }
>   }
>   private BrokerService createAndStartBroker() throws Exception {
>   BrokerService broker = new BrokerService();
>   broker.addConnector("stomp://localhost:61613");
>   broker.setStartAsync(false);
>   broker.setDeleteAllMessagesOnStartup(true);
>   broker.start();
>   return broker;
>   }
> }
> {code}
> For the initial read of the CONNECTED frame I see:
> {noformat}
> Time since last read: 49ms
> {noformat}
> However, it's then almost 20 seconds before a heart-beat's sent:
> {noformat}
> Time since last read: 19994ms
> {noformat}
> If I comment out the fail(…) line in the test, after the first heartbeat 
> taking almost 2ms to be sent, things settle down and a heartbeat's 
> received every 1ms.
> It looks like the write checker wakes up every 1ms. The first time it 
> wakes up, it notices that the CONNECTED frame was sent and does nothing. It 
> then sleeps for a further 1ms before checking again. As the CONNECTED 
> frame was sent very early in the first 1ms window, this leads to it 
> taking almost 2ms for the first heart-beat to be sent. From this point, 
> as no further data frames are sent, the write checker wakes up and sends a 
> heart-beat every 1ms.
> In short, I don't think ActiveMQ is adhering to the requirement that "the 
> sender MUST send new data over the network connection at least every  
> milliseconds".

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (AMQ-4533) Messages stuck in queue with redelivered=true

[Wieslaw Dudek (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-4533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Wieslaw Dudek updated AMQ-4533:
---

Attachment: AMQFreezeTest.zip

New AMQ "freeze" test case

> Messages stuck in queue with redelivered=true
> -
>
> Key: AMQ-4533
> URL: https://issues.apache.org/jira/browse/AMQ-4533
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: JMS client
>Affects Versions: 5.7.0
> Environment: Fuse Message Broker 5.7.0
>Reporter: Jason Shepherd
>Assignee: Gary Tully
> Fix For: 5.8.0
>
> Attachments: AMQ4533_logs.ZIP, AMQ4533Test.java, 
> AMQ4533TestPatch.txt, AMQ4533TestPatch.txt, AMQ4533TestPatch.txt, 
> AMQFreeze_logs.zip, AMQFreezeTest.zip, kahaPendingMessages.zip
>
>
> We're  getting message stuck in queues with the 
> redelivery flag set to true.
> We used the following test model: put every 1 second 50 messages 
> sequentially, and after that, the rest of 1000 msgs quickly to INPUT_QUEUE 
> and 
> while starting 25 listeners cosuming from INPUT_QUEUE, which takes about 30 
> seconds to move the message to RECEIPT_QUEUE, 10 other listeners on 
> RECEIPT_QUEUE consume and counts them.
> We tried making one of the consumer slow by setting the 
> processing time to 10 seconds (sleep) and putting a heavy load in 
> 500 threads every 1 ms to some other queues the same time.
> Our test case is attached, you might need to install some dependencies 
> to the local maven repository manually:
>  mvn install:install-file -DgroupId=org.apache.activemq 
> -DartifactId=activemq-core -Dversion=5.7.0-fuse-71-047 -Dpackaging=jar 
> -Dfile=activemq-core-5.7.0.fuse-71-047.jar
>  mvn install:install-file -DgroupId=org.apache.kahadb 
> -DartifactId=kahadb -Dversion=5.7.0-fuse-71-047 -Dpackaging=jar 
> -Dfile=kahadb-5.7.0.fuse-71-047.jar
>  mvn install:install-file 
> -DgroupId=org.apache.geronimo.management.specs 
> -DartifactId=geronimo-j2ee-management_1.1_spec -Dversion=1.0.1 
> -Dpackaging=jar -Dfile=geronimo-j2ee-management_1.1_spec-1.0.1.jar
>  mvn install:install-file -DgroupId=org.apache.activemq.pool 
> -DartifactId=activemq-pool -Dversion=5.7.0-fuse-71-047 -Dpackaging=jar 
> -Dfile=activemq-pool-5.7.0.fuse-71-047.jar
> To run the test, simply use the Maven test target:
> mvn clean test
> If the problem occurs the you'll get a message like this in the test 
> results, (target/surefire-reports):
> java.lang.AssertionError: Still messages in InputQueue expected:<0> 
> but was:<365>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (AMQ-4533) Messages stuck in queue with redelivered=true

[Wieslaw Dudek (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-4533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Wieslaw Dudek updated AMQ-4533:
---

Attachment: AMQFreeze_logs.zip

logs from failed AMQFreezeTest

> Messages stuck in queue with redelivered=true
> -
>
> Key: AMQ-4533
> URL: https://issues.apache.org/jira/browse/AMQ-4533
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: JMS client
>Affects Versions: 5.7.0
> Environment: Fuse Message Broker 5.7.0
>Reporter: Jason Shepherd
>Assignee: Gary Tully
> Fix For: 5.8.0
>
> Attachments: AMQ4533_logs.ZIP, AMQ4533Test.java, 
> AMQ4533TestPatch.txt, AMQ4533TestPatch.txt, AMQ4533TestPatch.txt, 
> AMQFreeze_logs.zip, AMQFreezeTest.zip, kahaPendingMessages.zip
>
>
> We're  getting message stuck in queues with the 
> redelivery flag set to true.
> We used the following test model: put every 1 second 50 messages 
> sequentially, and after that, the rest of 1000 msgs quickly to INPUT_QUEUE 
> and 
> while starting 25 listeners cosuming from INPUT_QUEUE, which takes about 30 
> seconds to move the message to RECEIPT_QUEUE, 10 other listeners on 
> RECEIPT_QUEUE consume and counts them.
> We tried making one of the consumer slow by setting the 
> processing time to 10 seconds (sleep) and putting a heavy load in 
> 500 threads every 1 ms to some other queues the same time.
> Our test case is attached, you might need to install some dependencies 
> to the local maven repository manually:
>  mvn install:install-file -DgroupId=org.apache.activemq 
> -DartifactId=activemq-core -Dversion=5.7.0-fuse-71-047 -Dpackaging=jar 
> -Dfile=activemq-core-5.7.0.fuse-71-047.jar
>  mvn install:install-file -DgroupId=org.apache.kahadb 
> -DartifactId=kahadb -Dversion=5.7.0-fuse-71-047 -Dpackaging=jar 
> -Dfile=kahadb-5.7.0.fuse-71-047.jar
>  mvn install:install-file 
> -DgroupId=org.apache.geronimo.management.specs 
> -DartifactId=geronimo-j2ee-management_1.1_spec -Dversion=1.0.1 
> -Dpackaging=jar -Dfile=geronimo-j2ee-management_1.1_spec-1.0.1.jar
>  mvn install:install-file -DgroupId=org.apache.activemq.pool 
> -DartifactId=activemq-pool -Dversion=5.7.0-fuse-71-047 -Dpackaging=jar 
> -Dfile=activemq-pool-5.7.0.fuse-71-047.jar
> To run the test, simply use the Maven test target:
> mvn clean test
> If the problem occurs the you'll get a message like this in the test 
> results, (target/surefire-reports):
> java.lang.AssertionError: Still messages in InputQueue expected:<0> 
> but was:<365>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (AMQ-4533) Messages stuck in queue with redelivered=true

[Wieslaw Dudek (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-4533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Wieslaw Dudek updated AMQ-4533:
---

Attachment: AMQ4533_logs.ZIP

DEBUG logs for failed TC AMQ4533 

> Messages stuck in queue with redelivered=true
> -
>
> Key: AMQ-4533
> URL: https://issues.apache.org/jira/browse/AMQ-4533
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: JMS client
>Affects Versions: 5.7.0
> Environment: Fuse Message Broker 5.7.0
>Reporter: Jason Shepherd
>Assignee: Gary Tully
> Fix For: 5.8.0
>
> Attachments: AMQ4533_logs.ZIP, AMQ4533Test.java, 
> AMQ4533TestPatch.txt, AMQ4533TestPatch.txt, AMQ4533TestPatch.txt, 
> kahaPendingMessages.zip
>
>
> We're  getting message stuck in queues with the 
> redelivery flag set to true.
> We used the following test model: put every 1 second 50 messages 
> sequentially, and after that, the rest of 1000 msgs quickly to INPUT_QUEUE 
> and 
> while starting 25 listeners cosuming from INPUT_QUEUE, which takes about 30 
> seconds to move the message to RECEIPT_QUEUE, 10 other listeners on 
> RECEIPT_QUEUE consume and counts them.
> We tried making one of the consumer slow by setting the 
> processing time to 10 seconds (sleep) and putting a heavy load in 
> 500 threads every 1 ms to some other queues the same time.
> Our test case is attached, you might need to install some dependencies 
> to the local maven repository manually:
>  mvn install:install-file -DgroupId=org.apache.activemq 
> -DartifactId=activemq-core -Dversion=5.7.0-fuse-71-047 -Dpackaging=jar 
> -Dfile=activemq-core-5.7.0.fuse-71-047.jar
>  mvn install:install-file -DgroupId=org.apache.kahadb 
> -DartifactId=kahadb -Dversion=5.7.0-fuse-71-047 -Dpackaging=jar 
> -Dfile=kahadb-5.7.0.fuse-71-047.jar
>  mvn install:install-file 
> -DgroupId=org.apache.geronimo.management.specs 
> -DartifactId=geronimo-j2ee-management_1.1_spec -Dversion=1.0.1 
> -Dpackaging=jar -Dfile=geronimo-j2ee-management_1.1_spec-1.0.1.jar
>  mvn install:install-file -DgroupId=org.apache.activemq.pool 
> -DartifactId=activemq-pool -Dversion=5.7.0-fuse-71-047 -Dpackaging=jar 
> -Dfile=activemq-pool-5.7.0.fuse-71-047.jar
> To run the test, simply use the Maven test target:
> mvn clean test
> If the problem occurs the you'll get a message like this in the test 
> results, (target/surefire-reports):
> java.lang.AssertionError: Still messages in InputQueue expected:<0> 
> but was:<365>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (AMQ-4533) Messages stuck in queue with redelivered=true

[Wieslaw Dudek (JIRA)]

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

Wieslaw Dudek commented on AMQ-4533:


It seems that the issue has not been resolved yet by introducing the timeout in 
AMQ-4621. See the logs from failed TC. We have another test case AMQFreeze 
which fails even the timeout is set using SlowAckConsumerStrategy. I attached 
the new TC. We should reopen AMQ-4533.

> Messages stuck in queue with redelivered=true
> -
>
> Key: AMQ-4533
> URL: https://issues.apache.org/jira/browse/AMQ-4533
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: JMS client
>Affects Versions: 5.7.0
> Environment: Fuse Message Broker 5.7.0
>Reporter: Jason Shepherd
>Assignee: Gary Tully
> Fix For: 5.8.0
>
> Attachments: AMQ4533Test.java, AMQ4533TestPatch.txt, 
> AMQ4533TestPatch.txt, AMQ4533TestPatch.txt, kahaPendingMessages.zip
>
>
> We're  getting message stuck in queues with the 
> redelivery flag set to true.
> We used the following test model: put every 1 second 50 messages 
> sequentially, and after that, the rest of 1000 msgs quickly to INPUT_QUEUE 
> and 
> while starting 25 listeners cosuming from INPUT_QUEUE, which takes about 30 
> seconds to move the message to RECEIPT_QUEUE, 10 other listeners on 
> RECEIPT_QUEUE consume and counts them.
> We tried making one of the consumer slow by setting the 
> processing time to 10 seconds (sleep) and putting a heavy load in 
> 500 threads every 1 ms to some other queues the same time.
> Our test case is attached, you might need to install some dependencies 
> to the local maven repository manually:
>  mvn install:install-file -DgroupId=org.apache.activemq 
> -DartifactId=activemq-core -Dversion=5.7.0-fuse-71-047 -Dpackaging=jar 
> -Dfile=activemq-core-5.7.0.fuse-71-047.jar
>  mvn install:install-file -DgroupId=org.apache.kahadb 
> -DartifactId=kahadb -Dversion=5.7.0-fuse-71-047 -Dpackaging=jar 
> -Dfile=kahadb-5.7.0.fuse-71-047.jar
>  mvn install:install-file 
> -DgroupId=org.apache.geronimo.management.specs 
> -DartifactId=geronimo-j2ee-management_1.1_spec -Dversion=1.0.1 
> -Dpackaging=jar -Dfile=geronimo-j2ee-management_1.1_spec-1.0.1.jar
>  mvn install:install-file -DgroupId=org.apache.activemq.pool 
> -DartifactId=activemq-pool -Dversion=5.7.0-fuse-71-047 -Dpackaging=jar 
> -Dfile=activemq-pool-5.7.0.fuse-71-047.jar
> To run the test, simply use the Maven test target:
> mvn clean test
> If the problem occurs the you'll get a message like this in the test 
> results, (target/surefire-reports):
> java.lang.AssertionError: Still messages in InputQueue expected:<0> 
> but was:<365>

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Memory leak in activemq-cpp (activemq-cpp-library-3.7.1)

[sunny_xu]

I really want to do something for this issue, unfortunately,I'm not familiar
with c++.

I just need a C++ client to access the shared memory information.

I wonder if this activemq-cpp package has been used in a production
enviroment.




--
View this message in context: 
http://activemq.2283324.n4.nabble.com/Memory-leak-in-activemq-cpp-activemq-cpp-library-3-7-1-tp4671248p4671288.html
Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.

[jira] [Updated] (AMQ-4621) Provide a polling SlowConsumerPolicy that uses LastAck time on a sub

[Jason Shepherd (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-4621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jason Shepherd updated AMQ-4621:


Attachment: kahaPendingMEssage-20130906.zip

I managed to fix the xml configuration issue, however this case still fails 
with the new strategy. Are you able to provide any insight into why this is 
still failing?

Note this the same test case as on AMQ-4533.

> Provide a polling SlowConsumerPolicy that uses LastAck time on a sub
> 
>
> Key: AMQ-4621
> URL: https://issues.apache.org/jira/browse/AMQ-4621
> Project: ActiveMQ
>  Issue Type: Improvement
>Affects Versions: 5.8.0
>Reporter: Gary Tully
>Assignee: Timothy Bish
>  Labels: abort, connection, consumer, policy, slowConsumers
> Fix For: 5.9.0
>
> Attachments: AMQ4621Patch.txt, kahaPendingMEssage-20130905.zip, 
> kahaPendingMEssage-20130906.zip
>
>
> The existing AbortSlowConsumer policy is event driven. It depends on a 
> consumer slow event that is triggered when the prefetch is reached and there 
> are subsequent dispatches.
> With prefetch=0|1 there still needs to be throughput to determine that the 
> consumer is slow so one message can be pending if there are no new messages 
> to sent to the destination.
> Providing an alternative implementation that will periodically poll consumers 
> for their last ack time will be more deterministic. The slow advisory may 
> never fire, but the consumer will get aborted if it does not ack in a timely 
> manner.
> if lastAckTime exceeds the max and there are dispatched messages it can be a 
> candidate for removal.
> Optionally lastAckTime exceeding and no dispatched messages can be a way to 
> remove idle consumers. Not sure if that is necessary.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira