On 2/15/19 10:12 PM, mill888 wrote:
I am using ActiveMq-cpp 3.9.4 and apache-apr 1.4.8 on redhat linux; and my
server program is multi thread;
In my program, I first create one producer and connect to ActiveMq;
In my server's program, I must dispose message firstly in every thread ,
after dispose it, then send the message to ActiveMq using the producer; all
threads are concurrent;
so I think , this model of server's program is common usage of AcitveMq
Client;
But I find, the memory usage increase continuously, and finally up to 100%
, and lastly the program collapse, you can use the command "top" to see the
result; or you can use command "ps -e -o 'pid,comm,pcpu,rsz,vsz'|grep test"
and look at the rsz value.
So I think the activemq-cpp of 3.9.4 version is of memory leak ?
In order to explain the problem clearly, I write a program named test.cpp,
and you can test it in three scenes as follows
(1) in main1 function, not use thread, no memory leak;
(2) in main function, use thread to send message; every 1 us create 20
detached threads ,every thread send message once , memory leak;
I think this is not the problem of thread creation , because If I
comment line "sup->PushByteMessage" in sendtomq_once, everything is ok, and
no memory leak;
(3) in main3 function, I create 7 threads, and In every thread I send
message repeatly, and no memory leak;
so , this problem is so amazing and ambiguous, because in (2) and (3) scene,
all use thread to send, but result are not the same; And I think it is not
the problem of the producer, Because in (1) scene, no memory leak;
This is memory leak of Activemq-cpp 3.9.4 , or because I not compiled it
correctly ?
Why ？And I test it in AIX using Acivemq-Cpp 3.9.4 , problem is the same ;
sorry for my poor English
testamq5.cpp
<http://activemq.2283324.n4.nabble.com/file/t379406/testamq5.cpp>
--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-Dev-f2368404.html
I'd suggest using common tooling such as Valgrind to look for the root
cause of the leak using the simplest test that can reproduce it, that
will likely be the quickest way for you to figure out what's going on.
--
Tim Bish
