Sorry to hear that - hopefully you'll get better results next time you
try
cheers,
Rob
On Jan 29, 2008, at 7:41 PM, Hellweek wrote:
After spending close to 2 months trying to get ActiveMQ to work
reliably we
have finaly decided to give up.
If some of you remember we were planning on us
After spending close to 2 months trying to get ActiveMQ to work reliably we
have finaly decided to give up.
If some of you remember we were planning on using ActiveMQ to distribute
pricing information for traders. As we were not able to get past some of
the issues we have with ActiveMQ it was de
I wish I could provide that. The problem happen on our production site and
only after about an hour of running. I managed to reproduce it once on test
machine after many tries. I had to create many publishers and many
consumers. On production mahcine it always happen (but at random times).
It see
If you experience problems - the best thing to do is to raise a
support issues (jira) , with a junit test case (hopefully one class -
look at the src for examples) asap
Provide details about your environment, the version of AMQ you are
running and any config information as well.
cheers,
Ro
I watch this thread with interest because I also have issues with activemq
and have not found any solution (using released version 5.0). I kind of lost
hope right now with using activemq.
I use Stomp for publisher and consumer. There are about 30 producers and 40
consumers each using their own co
Yes thanks for that. Test ran results posted.
nmittler wrote:
>
> Robert,
> I've captured what you have to do to change the timeout here
> http://issues.apache.org/activemq/browse/AMQCPP-157
>
> Regards,
> Nate
>
>
>>
>> Yes please tell me where to change the code for th etime out I will re
Robert,
I've captured what you have to do to change the timeout here
http://issues.apache.org/activemq/browse/AMQCPP-157
Regards,
Nate
Yes please tell me where to change the code for th etime out I will re
compile and try.
Yes please tell me where to change the code for th etime out I will re
compile and try.
James.Strachan wrote:
>
> On 17/12/2007, Nathan Mittler <[EMAIL PROTECTED]> wrote:
>> Hey James,
>> I've captured the details here
>> http://issues.apache.org/activemq/browse/AMQCPP-157
>
> Ah great, thanks.
The stack trace from the CPP client was added to one of the posts in this
thread.
I do think it is related to flow control.
James.Strachan wrote:
>
> On 17/12/2007, Hellweek <[EMAIL PROTECTED]> wrote:
>>
>> When performing the test with C# consumers the CPP producers fail.
>> The CPP consumer
On Dec 17, 2007, at 10:33 PM, James Mansion wrote:
Hellweek wrote:
When performing the test with C# consumers the CPP producers fail.
The CPP consumers do not fail with C# producers.
Perhaps the server should send one flow control message and require
that the client
ACK it specifically bef
Hellweek wrote:
When performing the test with C# consumers the CPP producers fail.
The CPP consumers do not fail with C# producers.
Perhaps the server should send one flow control message and require that
the client
ACK it specifically before sending another, to avoid spamming clients
that
I have not done anything to support the new flow control in the cpp
client, FYI.
Regards
Tim.
Mittler, Nathan wrote:
I guess if you know the broker can't accept any more
messages, there's no point trying to send & block; you could
maybe give a better error/log/exception back to the caller?
>
> I guess if you know the broker can't accept any more
> messages, there's no point trying to send & block; you could
> maybe give a better error/log/exception back to the caller?
Agreed! At the minimum, flow control should buy us the ability to
provide the user with a more meaningful error m
Awesome - thanks!
> -Original Message-
> From: James Strachan [mailto:[EMAIL PROTECTED]
> Sent: Monday, December 17, 2007 7:20 AM
> To: users@activemq.apache.org
> Subject: Re: ActiveMQ thoughts
>
> BTW I've just updated the documentation on producer flow
BTW I've just updated the documentation on producer flow control to
try describe what a good client should do (though its definitely an
optional feature)...
http://cwiki.apache.org/ACTIVEMQ/producer-flow-control.html
--
James
---
http://macstrac.blogspot.com/
Open Source Integration
http://o
On 17/12/2007, Nathan Mittler <[EMAIL PROTECTED]> wrote:
> Hey James,
> I've captured the details here
> http://issues.apache.org/activemq/browse/AMQCPP-157
Ah great, thanks. Sorry - I was being lazy not reading through all the
previous mails...
> Looks like the C++ producer's response correlat
Hey James,
I've captured the details here
http://issues.apache.org/activemq/browse/AMQCPP-157
Looks like the C++ producer's response correlator timed out when
waiting for a response for a sent bytes message (this timeout defaults
to 3 seconds).
It may simply be that the app was bogging dow
On 17/12/2007, Hellweek <[EMAIL PROTECTED]> wrote:
>
> When performing the test with C# consumers the CPP producers fail.
> The CPP consumers do not fail with C# producers.
Ah great, thanks. This has been a long thread, forgive me if you've
already answered this but how do they fail? Do they core
When performing the test with C# consumers the CPP producers fail.
The CPP consumers do not fail with C# producers.
Hiram Chirino wrote:
>
> Which one is the one that fails the C# side or the C++ side. And if
> you reverse the consumer / producer role is it still the same?
>
> On Dec 14, 2007
Which one is the one that fails the C# side or the C++ side. And if
you reverse the consumer / producer role is it still the same?
On Dec 14, 2007 4:50 PM, Hellweek <[EMAIL PROTECTED]> wrote:
>
> thats my thought also. however C# to C# work C++ to c++ works but C# to C++
> wont. Seems very odd.
thats my thought also. however C# to C# work C++ to c++ works but C# to C++
wont. Seems very odd.
nmittler wrote:
>
> Hey Rob,
> Agreed - this certainly smells of a flow control issue!
>
> The tricky bit is that two C++ clients can talk to each other without
> issue, whereas C#<->C++ doesn'
Hey Rob,
Agreed - this certainly smells of a flow control issue!
The tricky bit is that two C++ clients can talk to each other without
issue, whereas C#<->C++ doesn't work. Given that both clients are
talking to the broker, you would think this wouldn't make any
difference :)
Regards,
Na
Roger Hoover schrieb:
> Can anyone confirm or deny the second issue mentioned (what seems like the
> slow consumer problem)?
>
> "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 acc
This is good news. Please let me know if there is anything I can do.
I would love to retest this once it has been marked as resolved.
James.Strachan wrote:
>
> On 12/12/2007, Hellweek <[EMAIL PROTECTED]> wrote:
>>
>> Well my first impression was wrong also. I was assuming it was an issue
On 12/12/2007, Hellweek <[EMAIL PROTECTED]> wrote:
>
> 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 d
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
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.
>
>
It appears that it does not support C++ and is not as mature as ActiveMQ.
Hellweek wrote:
>
> I will examine this option today. Thanks for the heads up.
>
> Jonathan Share wrote:
>>
>> Hellweek wrote:
>>>
>>> Hello,
>>>
>>> I know what I am about to post will upset a few people, however I t
Daniel Pocock wrote:
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
Might not have answered that question very well for you.
We plan on using a mixed API enviroment.
For many of the exchanges we deal with we have to talk via C++ as most
exchanges do not support C#.
However once we are past the exchanges we plan on using C# as the primary
language. As such we o
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
The Test programs I provideded will demonstrate the issue. To be fair and
honest the issue seems to be an issue with using the C# API and C++ API.
Get the three test programs and you will see the the issue very clear.
Roger Hoover wrote:
>
> Can anyone confirm or deny the second issue menti
I had no real need for a JAVA API as such it was not included in our
evaluation.
James.Strachan wrote:
>
> On 11/12/2007, Hellweek <[EMAIL PROTECTED]> wrote:
>>
>> I pulled the 5.0 down yesterday. As well as the 5.0 RC1, RC2, RC3
>
> Cool thanks. BTW in your previous mail detailing your issues
Thanks,
I was not sure where I should open the JIRA issue. Will follow this issue
and retest once resolved.
nmittler wrote:
>
> Appreciate your feedback and helping to identify this problem! I've
> captured this in a JIRA issue here:
>
> https://issues.apache.org/activemq/browse/AMQCPP-157
I will examine this option today. Thanks for the heads up.
Jonathan Share wrote:
>
> 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
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 be
Hi Nathan,
I think we just need ensure that the C/C++/C# clients handle flow
control with the broker
cheers,
Rob
On Dec 12, 2007, at 4:05 AM, Nathan Mittler wrote:
Appreciate your feedback and helping to identify this problem! I've
captured this in a JIRA issue here:
https://issues.apa
On 11/12/2007, Hellweek <[EMAIL PROTECTED]> wrote:
>
> I pulled the 5.0 down yesterday. As well as the 5.0 RC1, RC2, RC3
Cool thanks. BTW in your previous mail detailing your issues I was a
little confused over what clients were being used - were you seeing
these issues purely with the C++ client
Can anyone confirm or deny the second issue mentioned (what seems like the
slow consumer problem)?
"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
Appreciate your feedback and helping to identify this problem! I've
captured this in a JIRA issue here:
https://issues.apache.org/activemq/browse/AMQCPP-157
We'll do our best to get this resolved soon!
Regards,
Nate
On Dec 11, 2007, at 9:10 AM, Hellweek wrote:
As promised I have created
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
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 th
As promised I have created a c++ test program (TestProducerBug) that will
create up to X producers. The class that does the work is
(TestProducers.cpp).
I am created a C# test program (TestConsumerBugCSharp) that will create up
to X consumers using a MessageListener. The class that does the work
I pulled the 5.0 down yesterday. As well as the 5.0 RC1, RC2, RC3
James.Strachan wrote:
>
> On 11/12/2007, Hellweek <[EMAIL PROTECTED]> wrote:
>>
>> Most of this testing was done with the 5.0 trunk.
>
> How long ago BTW? Only we've had a 5.0 trunk for about a year :)
>
>> thinking that it wa
On 11/12/2007, Hellweek <[EMAIL PROTECTED]> wrote:
>
> Most of this testing was done with the 5.0 trunk.
How long ago BTW? Only we've had a 5.0 trunk for about a year :)
> thinking that it was a
> problem with the 5.0 I tried on the 4.1 with even worse issues.
>
> Last night and today I finaly am
Most of this testing was done with the 5.0 trunk. thinking that it was a
problem with the 5.0 I tried on the 4.1 with even worse issues.
Last night and today I finaly am able to reproduce the issues I am seeing
and will be posting my test code.
While I can not currently use ActiveMQ in producti
On 10/12/2007, Hellweek <[EMAIL PROTECTED]> 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.
>
Appreciate the honest feeback!
Rob Davies
'Go further faster with Apache Camel!'
http://rajdavies.blogspot.com/
On Dec 10, 2007, at 9:31 PM, 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
48 matches
Mail list logo
