Well my first impression was wrong also. I was assuming it was an issue with C++ and the broker. However after extensive testing I am sure it is a problem with interop with C# and C++. I would hope you dont run into this issue.
I did get to testing C# to C# and I let it run full speed for over 3 hours sent and received more then 5 Million messages and it performed very well. For me that test was convincing enough to me that I am holding off on my Recomendation document. I am hoping that this is a fast easy fix. If it is I think I might just be able to still use ActiveMQ in production. yg_cvg wrote: > > Ah, I see. That's different from the impression I was initially getting > from your post. In particular, our clients would be Java servlets, so we > might not run into these issues. I am in the process of making some > stress tests myself right now. > > > Hellweek wrote: >> >> Here is what I can say. >> >> With the exception of the issue that I have posted about here I can tell >> you that I am very happy with the performance of ActiveMQ. >> >> As our applications depend on some for of MOM all of our applications use >> a common MessagingLayer. As such it took very little time for us to >> create this layer and instantly have our applications use it. >> >> I can tell you that the ActiveMQ is much faster then our existing MOM as >> such I was very excited about the possible improvments to performance. >> >> I think the issue I am reporting here is more an issue with >> Interoperability between C++ and C#. At least thats what it is looking >> like. A problem has been opened for this issue. This is a very positive >> sign. >> >> However, I can tell you that you should invest the time in exploring >> ActiveMQ. >> >> >> yg_cvg wrote: >>> >>> I am personally watching this thread with great interest, as we're >>> considering using ActiveMQ for a big highly distributed network, but we >>> have no idea how it would perform in such a setting. >>> >>> >>> Hellweek wrote: >>>> >>>> >>>> Hello, >>>> >>>> I know what I am about to post will upset a few people, however I think >>>> it is important that I document my experience with ActiveMQ in the >>>> hopes that others like me can have an understanding of the issues that >>>> you will face. >>>> >>>> A little history. >>>> >>>> I am not new to Open Source projects, have been involved in them and >>>> have sponsored the use of open source for many years. >>>> >>>> I have been working with various message brokers for a few years. My >>>> first experience was with TIBCO EMS. Needless to say I was very >>>> impressed with the stability and functionality of this fine EMS. Next >>>> I had the opportunity to work with Sonic EMS. Again I was impressed >>>> with this product and was even happier with its low cost of ownership. >>>> >>>> Over the last 6 weeks it has been my job to evaluate for our Trading >>>> firm an internal messaging system. We wanted to use a EMS solution for >>>> dissemination of pricing data to our in-house applications as well as >>>> external clients of ours. The messaging systems we are evaluating. >>>> TIBCO EMS, MSMQ 3.0, SONIC EMS, ACTIVEMQ 4.1.1 or ActieMQ 5.0. >>>> >>>> How did each product fair? >>>> 1. Tibco EMS no issues with any of the stress tests and performance >>>> tests. >>>> 2. MSMQ don't even get me started with this POS. >>>> 3. SONIC EMS no issues with any of the stress tests and performance >>>> tests. >>>> 4. ActiveMQ can not make it past any stress tests. See issues below >>>> for an understanding of what we saw. >>>> >>>> >>>> I have watched ActiveMQ for well over 2 years and 2 years ago the >>>> project was so filled with issues that I knew I would never be able to >>>> recommend it to the owners of the company. 2 Years later and I was in >>>> the position of trying ActiveMQ again and hoping that it would be >>>> stable. >>>> >>>> I was very pleased to see that many of the issues I saw with ActiveMQ >>>> had been resolved and was committed to giving ActiveMQ a chance at >>>> being our EMS solution for the future. However, I can say after weeks >>>> of testing ActiveMQ Is still not ready for production use by myself and >>>> the firm I work for. If you have high message throughput with high >>>> number of subscribers ActiveMQ is not well suited for your needs. >>>> >>>> Lets take some time to examine the issues. >>>> >>>> CPP ActiveMQ Client >>>> 1. A fast producer with slow clients can and will take down the >>>> producer. From what I have seen in testing a slow client can bring the >>>> producer down and in some cases can bring the broker down. A >>>> miss-behaved producer or client should never ever take the broker down. >>>> >>>> 2. A Producer that producers more then 200 messages per sec locks up >>>> the Broker when the Broker has only one client connected. This one was >>>> the biggest issue to accept and the one issue that caused us to say >>>> ActiveMQ is not ready for a production environment. The most basic and >>>> simple task of the Message Broker is not working as expected and makes >>>> the ActiveMQ unusable in a environment where peak message Generation >>>> can exceed 200 messages per second. To be honest we never even get >>>> close to 100 messages as it seems we die after 50 messages are fired in >>>> the same second. The only time I am able to have producers producing >>>> without locking up or crashing is if I don't have any consumers >>>> listening. Having a messaging system that works without consumers is >>>> not a valid solution. >>>> >>>> Again important to note. As long as no consumers are connected I can >>>> produce massive amounts of messages. Once you connect a client massive >>>> issues start to happen. >>>> >>>> 3. Producers and consumers created on the same connection can cause >>>> deadlocks. This is a major issue and the main solution is to not do >>>> this. However, this is an unacceptable solution as it is my >>>> understanding this is an acceptable practice. >>>> >>>> 4. A fast producer with a fast consumer leads to resource creep. I >>>> don't want to say it is a memory leak because it is not a leak it is >>>> just a very very slow release of the memory. I should not have to put >>>> sleeps in a program just to insure that memory gets released correctly. >>>> In my test I had to sleep for 20 MS between each message being sent to >>>> keep the ActiveMQ consumer running. >>>> >>>> 5. Placing a breakpoint on the message listener on a consumer will >>>> cause out of memory errors in the producer. Why me setting a >>>> breakpoint on a consumer can cause the producer to throw an exception >>>> is unacceptable and leads me to think that a slow consumer can and will >>>> take the broker and or producer down. >>>> >>>> 6. Very confusing to determine what version of ActiveMQ will work with >>>> what version of the client. Example ActiveMQ 5.0 was released this >>>> week. However, no new client was released and no information on when >>>> new client will be released. The CPP client just released a 2.1.3 >>>> version that claims it should be paired with 4.1.1 of the ActiveMQ >>>> broker. Where is the CPP client that is to work with the new features >>>> of 5.0? >>>> >>>> With all the issues I have I will not be able to go to a production >>>> environment with ActiveMQ, this is a shame as the people that have been >>>> working this project are talented people and should be commended for >>>> the work that has been done. >>>> >>> >>> >> >> > > -- View this message in context: http://www.nabble.com/ActiveMQ-thoughts-tp14262131s2354p14302923.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
