Re: ActiveMQ Blocked when memory is full

2009-02-19 Thread fehm

Hi,

seems like its still a problem in 5.2.0 (fuse 5.2.0.2).
The problem is quite easy to reproduce:
1.Limit the memoryUsage in activemq.xml to -say- 50MB. 
2.set producer flow control=false and disable saving messages to disk.
2.Start one producer publishing non-persistent messages with TTL=5sec in a
loop.
3.One/Several consumers receiving one message using consumer.receive() and
then sleep for a second (also in a loop).

You can sit back and watch the memory percent usage in JMX increasing. When
100% is reached the consumer stops receiving messages, but the producer
keeps running and therefore increasing the memory.
Starting a new consumer will result in this exception :


javax.jms.JMSException: Unexpected error occured
at
org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:49)
at
org.apache.activemq.ActiveMQConnection.onAsyncException(ActiveMQConnection.java:1773)
at
org.apache.activemq.ActiveMQConnection.onException(ActiveMQConnection.java:1790)
at
org.apache.activemq.transport.TransportFilter.onException(TransportFilter.java:99)
at
org.apache.activemq.transport.ResponseCorrelator.onException(ResponseCorrelator.java:114)
at
org.apache.activemq.transport.TransportFilter.onException(TransportFilter.java:99)
at
org.apache.activemq.transport.TransportFilter.onException(TransportFilter.java:99)
at
org.apache.activemq.transport.WireFormatNegotiator.onException(WireFormatNegotiator.java:152)
at
org.apache.activemq.transport.InactivityMonitor.onException(InactivityMonitor.java:244)
at
org.apache.activemq.transport.TransportSupport.onException(TransportSupport.java:96)
at
org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:194)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.io.IOException: Unexpected error occured
at
org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:192)
... 1 more
Caused by: java.lang.ClassCastException:
org.apache.activemq.command.BrokerId cannot be cast to
org.apache.activemq.command.ConsumerId
at
org.apache.activemq.openwire.v4.MessageMarshaller.tightUnmarshal(MessageMarshaller.java:75)
at
org.apache.activemq.openwire.v4.ActiveMQMessageMarshaller.tightUnmarshal(ActiveMQMessageMarshaller.java:66)
at
org.apache.activemq.openwire.v4.ActiveMQTextMessageMarshaller.tightUnmarshal(ActiveMQTextMessageMarshaller.java:66)
at
org.apache.activemq.openwire.OpenWireFormat.tightUnmarshalNestedObject(OpenWireFormat.java:453)
at
org.apache.activemq.openwire.v4.BaseDataStreamMarshaller.tightUnmarsalNestedObject(BaseDataStreamMarshaller.java:126)
at
org.apache.activemq.openwire.v4.MessageDispatchMarshaller.tightUnmarshal(MessageDispatchMarshaller.java:71)
at
org.apache.activemq.openwire.OpenWireFormat.doUnmarshal(OpenWireFormat.java:362)
at
org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat.java:276)
at
org.apache.activemq.transport.tcp.TcpTransport.readCommand(TcpTransport.java:210)
at
org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:202)
at
org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:185)
... 1 more


Sadly, only a broker restart solves the problem.

Cheers, Felix




rajdavies wrote:
 
 To be honest this looks like a bug in the Memory Usage stats  :( -  
 though I believe its fixed in the 5.2 release
 
 thanks,
 
 Rob
 
 On 7 Oct 2008, at 22:38, victorbp wrote:
 

 Thanks Rob!

 Now I'm able to receive all the messages using disk spooling, but I  
 see an
 odd behaviour: when the memory is full and the broker starts to save  
 the
 messages in disk, I can see in JConsole that the MemoryPercentUsage  
 property
 increases significantly, much higher than 100% (In some test the  
 value is
 close to 3000%).

 I'm not sure about this value, I guess that ActiveMQ takes all the  
 space
 (memory and disk) like the same and thats why I see this increase,  
 but what
 worries me is that once that the broker start to save in disk and  
 the memory
 is increased, it doesn't decrease, I mean, all the time is like the  
 memory
 was full, even if I don't send messages and all the previous  
 messages was
 consumed. Do you know if this is a normal behaviour or how can I  
 decrease
 this memory usage?

 Thanks a lot!
 -- 
 View this message in context:
 http://www.nabble.com/ActiveMQ-Blocked-when-memory-is-full-tp19841470p19867887.html
 Sent from the ActiveMQ - User mailing list archive at Nabble.com.

 
 
 

-- 
View this message in context: 
http://www.nabble.com/ActiveMQ-Blocked-when-memory-is-full-tp19841470p22098033.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.



Re: ActiveMQ Blocked when memory is full

2009-02-19 Thread Jim Gomes
This looks suspiciously related to a problem that we have been encountering,
but have been unable to narrow down.  I don't know if there is an existing
JIRA for this, but if there is, I'd vote for it.  Top priority.

Thanks for reporting your insights on this issue.

On Thu, Feb 19, 2009 at 2:57 AM, fehm felix@cern.ch wrote:


 Hi,

 seems like its still a problem in 5.2.0 (fuse 5.2.0.2).
 The problem is quite easy to reproduce:
 1.Limit the memoryUsage in activemq.xml to -say- 50MB.
 2.set producer flow control=false and disable saving messages to disk.
 2.Start one producer publishing non-persistent messages with TTL=5sec in a
 loop.
 3.One/Several consumers receiving one message using consumer.receive() and
 then sleep for a second (also in a loop).

 You can sit back and watch the memory percent usage in JMX increasing. When
 100% is reached the consumer stops receiving messages, but the producer
 keeps running and therefore increasing the memory.
 Starting a new consumer will result in this exception :


 javax.jms.JMSException: Unexpected error occured
at

 org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:49)
at

 org.apache.activemq.ActiveMQConnection.onAsyncException(ActiveMQConnection.java:1773)
at

 org.apache.activemq.ActiveMQConnection.onException(ActiveMQConnection.java:1790)
at

 org.apache.activemq.transport.TransportFilter.onException(TransportFilter.java:99)
at

 org.apache.activemq.transport.ResponseCorrelator.onException(ResponseCorrelator.java:114)
at

 org.apache.activemq.transport.TransportFilter.onException(TransportFilter.java:99)
at

 org.apache.activemq.transport.TransportFilter.onException(TransportFilter.java:99)
at

 org.apache.activemq.transport.WireFormatNegotiator.onException(WireFormatNegotiator.java:152)
at

 org.apache.activemq.transport.InactivityMonitor.onException(InactivityMonitor.java:244)
at

 org.apache.activemq.transport.TransportSupport.onException(TransportSupport.java:96)
at
 org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:194)
at java.lang.Thread.run(Thread.java:619)
 Caused by: java.io.IOException: Unexpected error occured
at
 org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:192)
... 1 more
 Caused by: java.lang.ClassCastException:
 org.apache.activemq.command.BrokerId cannot be cast to
 org.apache.activemq.command.ConsumerId
at

 org.apache.activemq.openwire.v4.MessageMarshaller.tightUnmarshal(MessageMarshaller.java:75)
at

 org.apache.activemq.openwire.v4.ActiveMQMessageMarshaller.tightUnmarshal(ActiveMQMessageMarshaller.java:66)
at

 org.apache.activemq.openwire.v4.ActiveMQTextMessageMarshaller.tightUnmarshal(ActiveMQTextMessageMarshaller.java:66)
at

 org.apache.activemq.openwire.OpenWireFormat.tightUnmarshalNestedObject(OpenWireFormat.java:453)
at

 org.apache.activemq.openwire.v4.BaseDataStreamMarshaller.tightUnmarsalNestedObject(BaseDataStreamMarshaller.java:126)
at

 org.apache.activemq.openwire.v4.MessageDispatchMarshaller.tightUnmarshal(MessageDispatchMarshaller.java:71)
at

 org.apache.activemq.openwire.OpenWireFormat.doUnmarshal(OpenWireFormat.java:362)
at

 org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat.java:276)
at

 org.apache.activemq.transport.tcp.TcpTransport.readCommand(TcpTransport.java:210)
at
 org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:202)
at
 org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:185)
... 1 more


 Sadly, only a broker restart solves the problem.

 Cheers, Felix




 rajdavies wrote:
 
  To be honest this looks like a bug in the Memory Usage stats  :( -
  though I believe its fixed in the 5.2 release
 
  thanks,
 
  Rob
 
  On 7 Oct 2008, at 22:38, victorbp wrote:
 
 
  Thanks Rob!
 
  Now I'm able to receive all the messages using disk spooling, but I
  see an
  odd behaviour: when the memory is full and the broker starts to save
  the
  messages in disk, I can see in JConsole that the MemoryPercentUsage
  property
  increases significantly, much higher than 100% (In some test the
  value is
  close to 3000%).
 
  I'm not sure about this value, I guess that ActiveMQ takes all the
  space
  (memory and disk) like the same and thats why I see this increase,
  but what
  worries me is that once that the broker start to save in disk and
  the memory
  is increased, it doesn't decrease, I mean, all the time is like the
  memory
  was full, even if I don't send messages and all the previous
  messages was
  consumed. Do you know if this is a normal behaviour or how can I
  decrease
  this memory usage?
 
  Thanks a lot!
  --
  View this message in context:
 
 http://www.nabble.com/ActiveMQ-Blocked-when-memory-is-full-tp19841470p19867887.html
  Sent from the ActiveMQ - User mailing

Re: ActiveMQ Blocked when memory is full

2008-10-08 Thread Rob Davies
To be honest this looks like a bug in the Memory Usage stats  :( -  
though I believe its fixed in the 5.2 release


thanks,

Rob

On 7 Oct 2008, at 22:38, victorbp wrote:



Thanks Rob!

Now I'm able to receive all the messages using disk spooling, but I  
see an
odd behaviour: when the memory is full and the broker starts to save  
the
messages in disk, I can see in JConsole that the MemoryPercentUsage  
property
increases significantly, much higher than 100% (In some test the  
value is

close to 3000%).

I'm not sure about this value, I guess that ActiveMQ takes all the  
space
(memory and disk) like the same and thats why I see this increase,  
but what
worries me is that once that the broker start to save in disk and  
the memory
is increased, it doesn't decrease, I mean, all the time is like the  
memory
was full, even if I don't send messages and all the previous  
messages was
consumed. Do you know if this is a normal behaviour or how can I  
decrease

this memory usage?

Thanks a lot!
--
View this message in context: 
http://www.nabble.com/ActiveMQ-Blocked-when-memory-is-full-tp19841470p19867887.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.





Re: ActiveMQ Blocked when memory is full

2008-10-07 Thread victorbp

Thanks Rob! 

Now I'm able to receive all the messages using disk spooling, but I see an
odd behaviour: when the memory is full and the broker starts to save the
messages in disk, I can see in JConsole that the MemoryPercentUsage property
increases significantly, much higher than 100% (In some test the value is
close to 3000%). 

I'm not sure about this value, I guess that ActiveMQ takes all the space
(memory and disk) like the same and thats why I see this increase, but what
worries me is that once that the broker start to save in disk and the memory
is increased, it doesn't decrease, I mean, all the time is like the memory
was full, even if I don't send messages and all the previous messages was
consumed. Do you know if this is a normal behaviour or how can I decrease
this memory usage?

Thanks a lot!
-- 
View this message in context: 
http://www.nabble.com/ActiveMQ-Blocked-when-memory-is-full-tp19841470p19867887.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.



ActiveMQ Blocked when memory is full

2008-10-06 Thread victorbp
/bean
/property
property name=pendingQueuePolicy
bean

class=org.apache.activemq.broker.region.policy.FilePendingQueueMessageStoragePolicy
/bean
/property
/bean
/property
/bean

-- 
View this message in context: 
http://www.nabble.com/ActiveMQ-Blocked-when-memory-is-full-tp19841470p19841470.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.