You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by robr <ro...@yahoo.com> on 2007/04/04 21:53:21 UTC

3.1 broker OutofMemoryError : unable to create new native thread

server Env:

  4 Gig Mem  with 2048M max JVM heap assigned to java

    Linux amq1 2.6.12-1.1447_FC4smp #1 SMP Fri Aug 26 21:03:12 EDT 2005
x86_64 x86_64 x86_64 GNU/Linux

JVM - java version "1.5.0_09"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_09-b03)
Java HotSpot(TM) Client VM (build 1.5.0_09-b03, mixed mode, sharing)

FAQ - if this JVM is 32 bit and i have 4G available, can i just increase
-Xmx from 2048M to 3500M and solve the problem by reacting directly to the
memory error?

Should i upgrade the broker from 3.1 to 3.2.2 to address the memory issue?
we are using persistence ( hypersonic DB?) and no journaling.
We process 600K messages per day. 

Im curious about what todo with this error if the JVM already has 2048M
allocated.

--- stacktrace

<code>
bug rept:
amq daemon 
t=59813,localport=61616]
 | 2007/04/04 04:20:54 | 04:20:54 WARN  run()
 | 2007/04/04 04:20:54 | java.lang.OutOfMemoryError: unable to create new
native thread
 | 2007/04/04 04:20:54 |       at java.lang.Thread.start0(Native Method)
 | 2007/04/04 04:20:54 |       at java.lang.Thread.start(Thread.java:574)
 | 2007/04/04 04:20:54 |       at 

org.activemq.transport.tcp.TcpTransportChannel.start(TcpTransportChannel.java:191)
 | 2007/04/04 04:20:54 |       at 

org.activemq.broker.impl.BrokerConnectorImpl.addClient(BrokerConnectorImpl.java:309)
 | 2007/04/04 04:20:54 |       at 

org.activemq.transport.TransportServerChannelSupport.addClient(TransportServerChannelSuppor

t.java:98)
 | 2007/04/04 04:20:54 |       at 

org.activemq.transport.tcp.TcpTransportServerChannel.run(TcpTransportServerChannel.java:158

)
 | 2007/04/04 04:20:54 |       at java.lang.Thread.run(Thread.java:595)
 | 2007/04/04 04:21:26 | 04:21:26 WARN  run()
 | 2007/04/04 04:21:26 | java.lang.OutOfMemoryError: unable to create new
native thread
 | 2007/04/04 04:21:26 |       at java.lang.Thread.start0(Native Method)
 | 2007/04/04 04:21:26 |       at java.lang.Thread.start(Thread.java:574)
 | 2007/04/04 04:21:26 |       at 

org.activemq.transport.tcp.TcpTransportChannel.start(TcpTransportChannel.java:191)
 | 2007/04/04 04:21:26 |       at 

org.activemq.broker.impl.BrokerConnectorImpl.addClient(BrokerConnectorImpl.java:309)
 | 2007/04/04 04:21:26 |       at 

org.activemq.transport.TransportServerChannelSupport.addClient(TransportServerChannelSuppor

t.java:98)
 | 2007/04/04 04:21:26 |       at 

org.activemq.transport.tcp.TcpTransportServerChannel.run(TcpTransportServerChannel.java:158

)
 | 2007/04/04 04:21:26 |       at java.lang.Thread.run(Thread.java:595)
 | 2007/04/04 04:21:58 | 04:21:58 WARN  run()
 | 2007/04/04 04:21:58 | java.lang.OutOfMemoryError: unable to create new
native thread
 | 2007/04/04 04:21:58 |       at java.lang.Thread.start0(Native Method)

</code>
-- 
View this message in context: http://www.nabble.com/3.1-broker-OutofMemoryError-%3A-unable-to-create-new-native-thread-tf3527977s2354.html#a9844430
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: 3.1 broker OutofMemoryError : unable to create new native thread

Posted by Kevan Miller <ke...@gmail.com>.
On Apr 4, 2007, at 3:53 PM, robr wrote:

>
> server Env:
>
>   4 Gig Mem  with 2048M max JVM heap assigned to java
>
>     Linux amq1 2.6.12-1.1447_FC4smp #1 SMP Fri Aug 26 21:03:12 EDT  
> 2005
> x86_64 x86_64 x86_64 GNU/Linux
>
> JVM - java version "1.5.0_09"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_09-b03)
> Java HotSpot(TM) Client VM (build 1.5.0_09-b03, mixed mode, sharing)
>
> FAQ - if this JVM is 32 bit and i have 4G available, can i just  
> increase
> -Xmx from 2048M to 3500M and solve the problem by reacting directly  
> to the
> memory error?
>
> Should i upgrade the broker from 3.1 to 3.2.2 to address the memory  
> issue?
> we are using persistence ( hypersonic DB?) and no journaling.
> We process 600K messages per day.
>
> Im curious about what todo with this error if the JVM already has  
> 2048M
> allocated.

I don't think increasing your heap memory will help you. In fact it  
could well hurt... You may actually find that reducing your heap size  
may help avoid this problem. Java (and your OS) will allocate non- 
heap memory for things like open files and Threads. Increasing your  
heap size can actually reduce the amount of memory available for  
these other purposes.

As I recall, you used to be able to configure how much stack memory  
was allocated per thread (-oss and -css? -- it's been a while since I  
dealt with these...). I'd start by reducing your heap size a bit  
(2048m -->  gigs -> 1536m, maybe).

--kevan

Re: 3.1 broker OutofMemoryError : unable to create new native thread

Posted by Ale Sarco <al...@sarco.com.ar>.
Replying myself:

Setting wireFormat.maxInactivityDuration=0 in the producers, solved the
problem of connections not being closed. However, I think this is a bug,
because the connection is not closed due to an exception being thrown by
something not related to the connection itself. I didn't see the source
code, but feels like the closing connection code not being inside a finally
block. 

Now, what I don't understand is why a TCP connection is created every time.
This happened no matter if I used ActiveMQ's PooledConnectionFactory or
Spring's SingleConnectionFactory. If I send 10000 messages at once, it will
use the same connection for all of them, but if there's an interval between
sending 2 messages, it will use 2 different connections. 

Any ideas?
Alex


Ale Sarco wrote:
> 
> Further investigation led to find this one, by setting the log to DEBUG.
> This happens when a new message is about to be received:
> 
> 2007-04-23 18:16:05,966 [ActiveMQ Transport: tcp:///127.0.0.1:54165] DEBUG
> org.apache.activemq.broker.region.AbstractRegion  - Removing consumer:
> ID:magellan-15043-1177347682999-1:9:-1:1
> 2007-04-23 18:16:05,967 [ActiveMQ Transport: tcp:///127.0.0.1:54165] DEBUG
> org.apache.activemq.broker.TransportConnection  - Stopping connection:
> /127.0.0.1:54165
> 2007-04-23 18:16:05,968 [ActiveMQ Transport: tcp:///127.0.0.1:54165] DEBUG
> org.apache.activemq.broker.TransportConnection  - Could not stop
> transport: java.lang.ClassCastException:
> org.apache.activemq.transport.InactivityMonitor$1
> java.lang.ClassCastException:
> org.apache.activemq.transport.InactivityMonitor$1
>         at
> edu.emory.mathcs.backport.java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.compareTo(ScheduledThreadPoolExecutor.java:189)
>         at
> edu.emory.mathcs.backport.java.util.PriorityQueue.remove(PriorityQueue.java:507)
>         at
> edu.emory.mathcs.backport.java.util.concurrent.DelayQueue.remove(DelayQueue.java:379)
>         ...
> 
> 2007-04-23 18:16:05,969 [ActiveMQ Transport Server: tcp://localhost:6002]
> DEBUG org.apache.activemq.transport.WireFormatNegotiator  - Sending:
> WireFormatInfo { version=2, properties={TightEncodingEnabled=true,
> CacheSize=1024, TcpNoDelayEnabled=true, SizePrefixDisabled=false,
> StackTraceEnabled=true, MaxInactivityDuration=30000, CacheEnabled=true},
> magic=[A,c,t,i,v,e,M,Q]}
> 2007-04-23 18:16:05,970 [ActiveMQ Transport: tcp:///127.0.0.1:54166] DEBUG
> org.apache.activemq.transport.WireFormatNegotiator  - Received WireFormat:
> WireFormatInfo { version=2, properties={TightEncodingEnabled=true,
> CacheSize=1024, TcpNoDelayEnabled=true, SizePrefixDisabled=false,
> StackTraceEnabled=true, MaxInactivityDuration=30000, CacheEnabled=true},
> magic=[A,c,t,i,v,e,M,Q]}
> 2007-04-23 18:16:05,970 [ActiveMQ Transport: tcp:///127.0.0.1:54166] DEBUG
> org.apache.activemq.transport.WireFormatNegotiator  -
> tcp:///127.0.0.1:54166 before negotiation: OpenWireFormat{version=2,
> cacheEnabled=false, stackTraceEnabled=false, tightEncodingEnabled=false,
> sizePrefixDisabled=false}
> 2007-04-23 18:16:05,970 [ActiveMQ Transport: tcp:///127.0.0.1:54166] DEBUG
> org.apache.activemq.transport.WireFormatNegotiator  -
> tcp:///127.0.0.1:54166 after negotiation: OpenWireFormat{version=2,
> cacheEnabled=true, stackTraceEnabled=true, tightEncodingEnabled=true,
> sizePrefixDisabled=false}
> 2007-04-23 18:16:05,970 [ActiveMQ Transport: tcp:///127.0.0.1:54166] DEBUG
> org.apache.activemq.broker.TransportConnection  - Setting up new
> connection:
> org.apache.activemq.broker.jmx.ManagedTransportConnection@b36b28
> 2007-04-23 18:16:06,011 [ActiveMQ Transport: tcp:///127.0.0.1:54166] DEBUG
> org.apache.activemq.broker.region.AbstractRegion  - Adding consumer:
> ID:magellan-15043-1177347682999-1:10:-1:1
> 
> So, for some reason, the old connection to the server cannot be closed
> because of that ClassCastException (might this be due to an
> InactivityMonitor instance being transferred with the message, and then
> being tried to be deserialized with a different classloader, as the
> producer and consumer are in 2 different webapps inside the same
> container?), and then another connection is created. Eventually, no more
> connections will be available.
> Why is the connection being tried to be closed in the first place, instead
> of being reused? Can this be avoided by setting
> wireFormat.maxInactivityDuration=0 in the broker? What would be the impact
> of doing this?
> 
> Thanks!
> Alex.
> 
> James.Strachan wrote:
>> 
>> On 4/17/07, Ale Sarco <al...@sarco.com.ar> wrote:
>>>
>>> Hi James,
>>>
>>> Using ActiveMQ 4.1.1 with Spring I experienced this "unable to create
>>> new
>>> native thread" exception in one of my production servers last night. The
>>> thing is that server does not has a large messaging traffic, it just
>>> send 2
>>> or 3 messages every couple of minutes to another webapp running in the
>>> same
>>> Tomcat, and this is only for 2 hours a day, and there were plenty of
>>> memory
>>> available on the heap for that VM.
>>> I agree that is probably related to the file descriptors that you
>>> mentioned,
>>> because when I tried to log in to that server via SSH I got an error
>>> about
>>> something like "insufficient resources". Only when I restarted the
>>> webapp I
>>> was able to login again.
>>> Now, what file descriptors is this about? Is a (logical) file created
>>> somewhere every time a message is sent? If so, how do I avoid this
>>> problem,
>>> I guess they should be reused or something?
>> 
>> File descriptors are often used for various things in the OS; files,
>> sockets, sometimes threads etc. ActiveMQ does not create a file or
>> socket per message :).
>> 
>> BTW how do things look in jconsole; do you have lots of connections on
>> your broker? I wonder if you are not closing connections after they
>> have been used (you are really meant to only use a small number of
>> connections and lots of sessions).
>> http://activemq.apache.org/how-do-i-use-jms-efficiently.html
>> 
>> Just up the file descriptors setting on your OS and it should fix this
>> 
>> 
>> -- 
>> 
>> James
>> -------
>> http://radio.weblogs.com/0112098/
>> 
>> 
> 
> 



-- 
View this message in context: http://www.nabble.com/3.1-broker-OutofMemoryError-%3A-unable-to-create-new-native-thread-tf3527977s2354.html#a10160068
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: 3.1 broker OutofMemoryError : unable to create new native thread

Posted by Ale Sarco <al...@sarco.com.ar>.
Further investigation led to find this one, by setting the log to DEBUG. This
happens when a new message is about to be received:

2007-04-23 18:16:05,966 [ActiveMQ Transport: tcp:///127.0.0.1:54165] DEBUG
org.apache.activemq.broker.region.AbstractRegion  - Removing consumer:
ID:magellan-15043-1177347682999-1:9:-1:1
2007-04-23 18:16:05,967 [ActiveMQ Transport: tcp:///127.0.0.1:54165] DEBUG
org.apache.activemq.broker.TransportConnection  - Stopping connection:
/127.0.0.1:54165
2007-04-23 18:16:05,968 [ActiveMQ Transport: tcp:///127.0.0.1:54165] DEBUG
org.apache.activemq.broker.TransportConnection  - Could not stop transport:
java.lang.ClassCastException:
org.apache.activemq.transport.InactivityMonitor$1
java.lang.ClassCastException:
org.apache.activemq.transport.InactivityMonitor$1
        at
edu.emory.mathcs.backport.java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.compareTo(ScheduledThreadPoolExecutor.java:189)
        at
edu.emory.mathcs.backport.java.util.PriorityQueue.remove(PriorityQueue.java:507)
        at
edu.emory.mathcs.backport.java.util.concurrent.DelayQueue.remove(DelayQueue.java:379)
        ...

2007-04-23 18:16:05,969 [ActiveMQ Transport Server: tcp://localhost:6002]
DEBUG org.apache.activemq.transport.WireFormatNegotiator  - Sending:
WireFormatInfo { version=2, properties={TightEncodingEnabled=true,
CacheSize=1024, TcpNoDelayEnabled=true, SizePrefixDisabled=false,
StackTraceEnabled=true, MaxInactivityDuration=30000, CacheEnabled=true},
magic=[A,c,t,i,v,e,M,Q]}
2007-04-23 18:16:05,970 [ActiveMQ Transport: tcp:///127.0.0.1:54166] DEBUG
org.apache.activemq.transport.WireFormatNegotiator  - Received WireFormat:
WireFormatInfo { version=2, properties={TightEncodingEnabled=true,
CacheSize=1024, TcpNoDelayEnabled=true, SizePrefixDisabled=false,
StackTraceEnabled=true, MaxInactivityDuration=30000, CacheEnabled=true},
magic=[A,c,t,i,v,e,M,Q]}
2007-04-23 18:16:05,970 [ActiveMQ Transport: tcp:///127.0.0.1:54166] DEBUG
org.apache.activemq.transport.WireFormatNegotiator  - tcp:///127.0.0.1:54166
before negotiation: OpenWireFormat{version=2, cacheEnabled=false,
stackTraceEnabled=false, tightEncodingEnabled=false,
sizePrefixDisabled=false}
2007-04-23 18:16:05,970 [ActiveMQ Transport: tcp:///127.0.0.1:54166] DEBUG
org.apache.activemq.transport.WireFormatNegotiator  - tcp:///127.0.0.1:54166
after negotiation: OpenWireFormat{version=2, cacheEnabled=true,
stackTraceEnabled=true, tightEncodingEnabled=true, sizePrefixDisabled=false}
2007-04-23 18:16:05,970 [ActiveMQ Transport: tcp:///127.0.0.1:54166] DEBUG
org.apache.activemq.broker.TransportConnection  - Setting up new connection:
org.apache.activemq.broker.jmx.ManagedTransportConnection@b36b28
2007-04-23 18:16:06,011 [ActiveMQ Transport: tcp:///127.0.0.1:54166] DEBUG
org.apache.activemq.broker.region.AbstractRegion  - Adding consumer:
ID:magellan-15043-1177347682999-1:10:-1:1

So, for some reason, the old connection to the server cannot be closed
because of that ClassCastException (might this be due to an
InactivityMonitor instance being transferred with the message, and then
being tried to be deserialized with a different classloader, as the producer
and consumer are in 2 different webapps inside the same container?), and
then another connection is created. Eventually, no more connections will be
available.
Why is the connection being tried to be closed in the first place, instead
of being reused? Can this be avoided by setting
wireFormat.maxInactivityDuration=0 in the broker? What would be the impact
of doing this?

Thanks!
Alex.

James.Strachan wrote:
> 
> On 4/17/07, Ale Sarco <al...@sarco.com.ar> wrote:
>>
>> Hi James,
>>
>> Using ActiveMQ 4.1.1 with Spring I experienced this "unable to create new
>> native thread" exception in one of my production servers last night. The
>> thing is that server does not has a large messaging traffic, it just send
>> 2
>> or 3 messages every couple of minutes to another webapp running in the
>> same
>> Tomcat, and this is only for 2 hours a day, and there were plenty of
>> memory
>> available on the heap for that VM.
>> I agree that is probably related to the file descriptors that you
>> mentioned,
>> because when I tried to log in to that server via SSH I got an error
>> about
>> something like "insufficient resources". Only when I restarted the webapp
>> I
>> was able to login again.
>> Now, what file descriptors is this about? Is a (logical) file created
>> somewhere every time a message is sent? If so, how do I avoid this
>> problem,
>> I guess they should be reused or something?
> 
> File descriptors are often used for various things in the OS; files,
> sockets, sometimes threads etc. ActiveMQ does not create a file or
> socket per message :).
> 
> BTW how do things look in jconsole; do you have lots of connections on
> your broker? I wonder if you are not closing connections after they
> have been used (you are really meant to only use a small number of
> connections and lots of sessions).
> http://activemq.apache.org/how-do-i-use-jms-efficiently.html
> 
> Just up the file descriptors setting on your OS and it should fix this
> 
> 
> -- 
> 
> James
> -------
> http://radio.weblogs.com/0112098/
> 
> 



-- 
View this message in context: http://www.nabble.com/3.1-broker-OutofMemoryError-%3A-unable-to-create-new-native-thread-tf3527977s2354.html#a10145361
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: 3.1 broker OutofMemoryError : unable to create new native thread

Posted by Ale Sarco <al...@sarco.com.ar>.
Hi James,

It happened again friday night on a different production server (same
application). I have duplicated the file handlers (to 103062) for the OS
(Fedora Core 3), but it seems like the important setting here is a per user
setting, since whenever this happens, I cannot login into the account in
which Tomcat is running (Resource temporarily unavailable), but I can to any
other, until I shut Tomcat down. The used file handlers at the time of the
exception was just 3090. 

Anyway, apart from the file handlers setting, I think something must be
wrong with my configuration.
This is my Spring consumer config:

	<bean id="connectionFactory"
class="org.apache.activemq.pool.PooledConnectionFactory">
		<property name="connectionFactory">
			<bean class="org.apache.activemq.ActiveMQConnectionFactory">
				<property name="brokerURL"
value="vm:(broker:(tcp://localhost:6001)?persistent=false)" />
			</bean>
		</property>
	</bean>	
    <bean id="messageReceiver"
class="tv.nation217.phoenix.services.messaging.MessageReceiver" />
    <bean id="callerWarningListener"
class="org.springframework.jms.listener.adapter.MessageListenerAdapter">
        <property name="delegate" ref="messageReceiver"/>
        <property name="defaultListenerMethod"
value="onCallerWarningReceive"/>
    </bean>
	<bean id="callerWarningContainer"
class="org.springframework.jms.listener.SimpleMessageListenerContainer">
        <property name="connectionFactory" ref="connectionFactory"/>
        <property name="messageListener" ref="callerWarningListener"/>
        <property name="destinationName" value="callerWarningQ"/>
    </bean>
    <!-- three more consumers... -->

And this is the producer Spring config:

	<bean id="connectionFactory"
class="org.apache.activemq.pool.PooledConnectionFactory">
		<property name="connectionFactory">
			<bean class="org.apache.activemq.ActiveMQConnectionFactory">
				<property name="brokerURL" value="tcp://localhost:6001" />
			</bean>
		</property>
	</bean>
	<bean id="jmsTemplate" class="org.springframework.jms.core.JmsTemplate">
	    <property name="connectionFactory" ref="connectionFactory" />
	</bean>
	<bean id="messageProducer"
class="tv.nation217.phoenix.poller.messaging.MessageProducer">
		<property name="jmsTemplate" ref="jmsTemplate"/>			
	</bean>


Do you see anything wrong in here?

Many thanks,
Alex.




James.Strachan wrote:
> 
> On 4/17/07, Ale Sarco <al...@sarco.com.ar> wrote:
>>
>> Hi James,
>>
>> Using ActiveMQ 4.1.1 with Spring I experienced this "unable to create new
>> native thread" exception in one of my production servers last night. The
>> thing is that server does not has a large messaging traffic, it just send
>> 2
>> or 3 messages every couple of minutes to another webapp running in the
>> same
>> Tomcat, and this is only for 2 hours a day, and there were plenty of
>> memory
>> available on the heap for that VM.
>> I agree that is probably related to the file descriptors that you
>> mentioned,
>> because when I tried to log in to that server via SSH I got an error
>> about
>> something like "insufficient resources". Only when I restarted the webapp
>> I
>> was able to login again.
>> Now, what file descriptors is this about? Is a (logical) file created
>> somewhere every time a message is sent? If so, how do I avoid this
>> problem,
>> I guess they should be reused or something?
> 
> File descriptors are often used for various things in the OS; files,
> sockets, sometimes threads etc. ActiveMQ does not create a file or
> socket per message :).
> 
> BTW how do things look in jconsole; do you have lots of connections on
> your broker? I wonder if you are not closing connections after they
> have been used (you are really meant to only use a small number of
> connections and lots of sessions).
> http://activemq.apache.org/how-do-i-use-jms-efficiently.html
> 
> Just up the file descriptors setting on your OS and it should fix this
> 
> 
> -- 
> 
> James
> -------
> http://radio.weblogs.com/0112098/
> 
> 

-- 
View this message in context: http://www.nabble.com/3.1-broker-OutofMemoryError-%3A-unable-to-create-new-native-thread-tf3527977s2354.html#a10136935
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: 3.1 broker OutofMemoryError : unable to create new native thread

Posted by James Strachan <ja...@gmail.com>.
On 4/17/07, Ale Sarco <al...@sarco.com.ar> wrote:
>
> Hi James,
>
> Using ActiveMQ 4.1.1 with Spring I experienced this "unable to create new
> native thread" exception in one of my production servers last night. The
> thing is that server does not has a large messaging traffic, it just send 2
> or 3 messages every couple of minutes to another webapp running in the same
> Tomcat, and this is only for 2 hours a day, and there were plenty of memory
> available on the heap for that VM.
> I agree that is probably related to the file descriptors that you mentioned,
> because when I tried to log in to that server via SSH I got an error about
> something like "insufficient resources". Only when I restarted the webapp I
> was able to login again.
> Now, what file descriptors is this about? Is a (logical) file created
> somewhere every time a message is sent? If so, how do I avoid this problem,
> I guess they should be reused or something?

File descriptors are often used for various things in the OS; files,
sockets, sometimes threads etc. ActiveMQ does not create a file or
socket per message :).

BTW how do things look in jconsole; do you have lots of connections on
your broker? I wonder if you are not closing connections after they
have been used (you are really meant to only use a small number of
connections and lots of sessions).
http://activemq.apache.org/how-do-i-use-jms-efficiently.html

Just up the file descriptors setting on your OS and it should fix this


-- 

James
-------
http://radio.weblogs.com/0112098/

Re: 3.1 broker OutofMemoryError : unable to create new native thread

Posted by Ale Sarco <al...@sarco.com.ar>.
Hi James,

Using ActiveMQ 4.1.1 with Spring I experienced this "unable to create new
native thread" exception in one of my production servers last night. The
thing is that server does not has a large messaging traffic, it just send 2
or 3 messages every couple of minutes to another webapp running in the same
Tomcat, and this is only for 2 hours a day, and there were plenty of memory
available on the heap for that VM.
I agree that is probably related to the file descriptors that you mentioned,
because when I tried to log in to that server via SSH I got an error about
something like "insufficient resources". Only when I restarted the webapp I
was able to login again. 
Now, what file descriptors is this about? Is a (logical) file created
somewhere every time a message is sent? If so, how do I avoid this problem,
I guess they should be reused or something?

Thanks,
Alex.



James.Strachan wrote:
> 
> 3.1 is ancient, you might wanna upgrade to 4.1.1
> 
> FWIW your issue is probably you ran out of file descriptors
> 
> On 4/4/07, robr <ro...@yahoo.com> wrote:
>>
> 
> 
> -- 
> 
> James
> -------
> http://radio.weblogs.com/0112098/
> 
> 

-- 
View this message in context: http://www.nabble.com/3.1-broker-OutofMemoryError-%3A-unable-to-create-new-native-thread-tf3527977s2354.html#a10032556
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: 3.1 broker OutofMemoryError : unable to create new native thread

Posted by James Strachan <ja...@gmail.com>.
3.1 is ancient, you might wanna upgrade to 4.1.1

FWIW your issue is probably you ran out of file descriptors

On 4/4/07, robr <ro...@yahoo.com> wrote:
>
> server Env:
>
>   4 Gig Mem  with 2048M max JVM heap assigned to java
>
>     Linux amq1 2.6.12-1.1447_FC4smp #1 SMP Fri Aug 26 21:03:12 EDT 2005
> x86_64 x86_64 x86_64 GNU/Linux
>
> JVM - java version "1.5.0_09"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_09-b03)
> Java HotSpot(TM) Client VM (build 1.5.0_09-b03, mixed mode, sharing)
>
> FAQ - if this JVM is 32 bit and i have 4G available, can i just increase
> -Xmx from 2048M to 3500M and solve the problem by reacting directly to the
> memory error?
>
> Should i upgrade the broker from 3.1 to 3.2.2 to address the memory issue?
> we are using persistence ( hypersonic DB?) and no journaling.
> We process 600K messages per day.
>
> Im curious about what todo with this error if the JVM already has 2048M
> allocated.
>
> --- stacktrace
>
> <code>
> bug rept:
> amq daemon
> t=59813,localport=61616]
>  | 2007/04/04 04:20:54 | 04:20:54 WARN  run()
>  | 2007/04/04 04:20:54 | java.lang.OutOfMemoryError: unable to create new
> native thread
>  | 2007/04/04 04:20:54 |       at java.lang.Thread.start0(Native Method)
>  | 2007/04/04 04:20:54 |       at java.lang.Thread.start(Thread.java:574)
>  | 2007/04/04 04:20:54 |       at
>
> org.activemq.transport.tcp.TcpTransportChannel.start(TcpTransportChannel.java:191)
>  | 2007/04/04 04:20:54 |       at
>
> org.activemq.broker.impl.BrokerConnectorImpl.addClient(BrokerConnectorImpl.java:309)
>  | 2007/04/04 04:20:54 |       at
>
> org.activemq.transport.TransportServerChannelSupport.addClient(TransportServerChannelSuppor
>
> t.java:98)
>  | 2007/04/04 04:20:54 |       at
>
> org.activemq.transport.tcp.TcpTransportServerChannel.run(TcpTransportServerChannel.java:158
>
> )
>  | 2007/04/04 04:20:54 |       at java.lang.Thread.run(Thread.java:595)
>  | 2007/04/04 04:21:26 | 04:21:26 WARN  run()
>  | 2007/04/04 04:21:26 | java.lang.OutOfMemoryError: unable to create new
> native thread
>  | 2007/04/04 04:21:26 |       at java.lang.Thread.start0(Native Method)
>  | 2007/04/04 04:21:26 |       at java.lang.Thread.start(Thread.java:574)
>  | 2007/04/04 04:21:26 |       at
>
> org.activemq.transport.tcp.TcpTransportChannel.start(TcpTransportChannel.java:191)
>  | 2007/04/04 04:21:26 |       at
>
> org.activemq.broker.impl.BrokerConnectorImpl.addClient(BrokerConnectorImpl.java:309)
>  | 2007/04/04 04:21:26 |       at
>
> org.activemq.transport.TransportServerChannelSupport.addClient(TransportServerChannelSuppor
>
> t.java:98)
>  | 2007/04/04 04:21:26 |       at
>
> org.activemq.transport.tcp.TcpTransportServerChannel.run(TcpTransportServerChannel.java:158
>
> )
>  | 2007/04/04 04:21:26 |       at java.lang.Thread.run(Thread.java:595)
>  | 2007/04/04 04:21:58 | 04:21:58 WARN  run()
>  | 2007/04/04 04:21:58 | java.lang.OutOfMemoryError: unable to create new
> native thread
>  | 2007/04/04 04:21:58 |       at java.lang.Thread.start0(Native Method)
>
> </code>
> --
> View this message in context: http://www.nabble.com/3.1-broker-OutofMemoryError-%3A-unable-to-create-new-native-thread-tf3527977s2354.html#a9844430
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
>


-- 

James
-------
http://radio.weblogs.com/0112098/