You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by Manuel Teira <mt...@tid.es> on 2007/06/27 12:26:12 UTC
About releases and bugs
Hello.
I will try to outline briefly our situation as activemq users:
We are embedding a 4.0.2 broker in our system. It is suffering some
problems:
- Memory leaks.
- Locks trying to create or delete temporary queues (AMQ-1278). Still
trying to reproduce it to verify this bug as fixed for us.
- Inactivity exceptions in running channels, perhaps related with the
leaks and the GC monopolizing the CPU time.
We are in the process of migrating to activemq 4.1.1. In our tests, as
I've commented in a previous mail, we have found that:
- Memory leaks are still happening, at least while creating temporary
queues and consumers (AMQ-1297)
As this bug is a stopper for us, we tried, as it's usually recommended,
with more recent snapshots, to see if the problems were fixed. So, we
have found, using the more recent 5.0 snapshot:
- The memory leaks seems to be fixed.
- Already delete messages can be browsed using the JMX console (AMQ-1296)
- Messages are (hardly ever, but happens) duplicated or not delivered.
(AMQ-1295)
- What seems random Inactivity exceptions in running and active
channels. Perhaps related with AMQ-1146.
So, my first question is about next releases. I think I've read somewere
that there will be a 4.1.2 release. I suppose that generated from svn
branches/activemq-4.1. However, a recent fix like the one for AMQ-1146
(related with the inactivity IO exceptions), was not applied on this
branch. So, what does this mean? That this bug won't be fixed in a
future 4.1.x release? That there would be no more 4.1.x ?
In the current situation, I think that the best release for us is 4.1.1,
if we were able to fix the leakages (5.0 found bugs are stoppers for
us). Any idea of what changes could have fixed that leakage? I've also
started to inspect the source code of the project. I have to say that,
at a first glance, it looks great, well-organized and very modular. But
it's hard for a newcomer to understand the whole thing and to find out
where the different pieces go. Is there any guide for developers that
could ease the learning process ?
Thanks, and best regards.
Re: About releases and bugs
Posted by New User <es...@indoles.com>.
James et. al.
Here's my experience with activemq.
I have a need to transfer large files over a WAN (involves multiple
machines, and at times unreliable network hops).
There files are generated at pretty much random intervals. I started around
when 4.0 was being moved into the apache world.
So, the set up ended up consisting of 4 machines:
Producer --> BrokerA --> <<WAN>> --> BrokerA --> Consumer
Broker A and B with a failover connection between them.
Invariably when the WAN has burbs of some sort either of the brokers would
get stuck. Sometimes restarting one or both brokers would fix the problem.
Sometimes restart would result in lost messages. Other times only removing
the derby storage as part of restart would work (resulting in lots of lost
messages).
So, I tried all kinds of things, like writing a client that forwards the
messages (consumes from one broker and produces the messages on the other),
this too would have to use a failover connection. Same problems would
persist.
As new versions of software came out, I would upgrade and never get rid of
the problem. (The last I tried was some sort of 4.2 rc, it's been a while).
Lots of the 'fixed bugs' listed sounded like they would fix my problem, but
they never did.
So, I gave up (ended up writing a couple of erlang programs in about 4 hours
to accomplish the task).
Now I understand the nature of open source software, have contributed to my
share of them, so please don't say 'why didn't you just fix the code,
produce stack traces, etc.' Simple answer is that I didn't have time, and
when a problem occured (once in every 24 to 48 hours) it was most important
to fight the fire (I understand the stupidity of that also).
So, why am I writing this...
Because I think the approach taken to bug fixing in activemq is wrong.
Basically bug are fixed against the trunk. They should be fixed 1st against
a 'supported version' if the bug is applicable to that version.
That is if a bug exists in 4.1.1, it should be fixed in the 4.1 branch 1st,
then merged to the trunk.
In my world I can not be chasing the latest greatest all the time and take
the risk of new bugs being introduced due to features under development.
So, I kind of wish that activemq'd have a bug fixing policy along the lines
above, and it would be strictly adhered to. This would, of course, mean that
there'd have to be one (or maybe two) 'supported versions' at any given
time.
Thanks for listening,
Esa
On 6/28/07, Tom Samplonius <to...@samplonius.org> wrote:
>
> I have to agree with most of this. ActiveMQ is a buggy as hell.
Thats a bit of an exaggeration & a comment thats hardly likely to get
the volunteers on the list to help you solve your particular issues.
--
View this message in context: http://www.nabble.com/About-releases-and-bugs-tf3987476s2354.html#a11363047
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: About releases and bugs
Posted by Nicky Sandhu <ni...@hotmail.com>.
James.Strachan wrote:
>
> On 6/28/07, Tom Samplonius <to...@samplonius.org> wrote:
>>
>> I have to agree with most of this. ActiveMQ is a buggy as hell.
>
> Thats a bit of an exaggeration & a comment thats hardly likely to get
> the volunteers on the list to help you solve your particular issues.
>
>
Waiting for the dust to settle ....
OK. I think I have spent a few days with ActiveMQ and am working through
various problems. The speed of development is very high (which is a good
thing) but usually leads to instability in the transition period. It also
leaves the documentation lacking.
I have been checking out the trunk and importing it as an eclipse project.
it is very well written and the unit tests are there for those inclined to
write them. I know it takes some time but it would be better to hit James
and team with reproducible tests (at minimum) and patches (ideally).
I would like to see a ActiveMQ testing kit evolve independently of the
ActiveMQ version that tests ActiveMQ from a JMS client, failover, guarenteed
delivery etc prespective. I see the testcases under
org.apache.activemq.usecases as a starting point.
These are different from unit test cases that have to be closely tied to
implementation classes. These tests would test ActiveMQ as an external
system so would depend upon config files and the like but will test ActiveMQ
from a users prespective. This would also include simulating crashes with
real world emphasis like doing a kill -9 on activemq broker and recovering
from that.
This would help fight FUD and give ActiveMQ the stability desired from a
user prespective while allowing for rapid development of new features.
--
View this message in context: http://www.nabble.com/About-releases-and-bugs-tf3987476s2354.html#a11364092
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Being serious about "secure by design" (was Re: About releases and
bugs)
Posted by Tom Samplonius <to...@samplonius.org>.
----- "James Strachan" <ja...@gmail.com> wrote:
...
> > Authentication and security should be mandatory, but the
> ActiveMQ.Agent feature doesn't work if auth is enabled.
>
> I'm not aware of any any MOM where authentication and security are
> mandatory out of the box; its usually always something you configure
> using whatever technologies you like.
No James, I think you missed the point: authentication of any kind can't be used at the same time as ActiveMQ.Agenet. ActiveMQ will crash on start.
So ActiveMQ.Agent is completely incompatible with authentication. This is a design flaw. And it does not fit with the "secure by design" philosophy.
> > Neither does the Web Console queueBrowser. These components should
> be move to a sandbox.
>
> Huh?
The Web Console queueBrowser is also incompatible with authentication. If you use authentication, the queueBrowser crashes.
So, in keeping with the "secure by design" philosophy, the Web Console and ActiveMQ.Agent should be moved to a sandbox, until someone fixes them. I think this is a completely reasonable approach.
Tom
Re: About releases and bugs
Posted by James Strachan <ja...@gmail.com>.
On 6/28/07, Tom Samplonius <to...@samplonius.org> wrote:
>
> I have to agree with most of this. ActiveMQ is a buggy as hell.
Thats a bit of an exaggeration & a comment thats hardly likely to get
the volunteers on the list to help you solve your particular issues.
> In my testing, I'd have to say ActiveMQ 4.1.1 is completely unusable in production. I'm told that it is used in production somewhere, but I suspect the usage is extremely narrow.
Its used in production by many companies right now in heaps of
different scenarios. Just because your exact requirements are not met
100% does not imply that many other people are not using the project
to great effect
> I'd like to know what usage actually works. So if you are using ActiveMQ in production, how are you using it?
>
> The show-stopping bugs in 4.1.1 are:
>
> - ActiveMQ loses unacked messages if a Stomp client disconnects without an explicit DISCONNECT (fixed in 4.2-something)
>
> - Stomp server does not support authentication. It is completely wide-open. And the default install has a Stomp listener running, so ActiveMQ is wide open if you have Stomp enabled (there is an unofficial patch, but I don't think this one will even be fixed in 5.0).
So you've found 2 issues with the stomp support (which BTW is a
totally optional feature); one is already fixed as you say and another
is a pretty trivial fix and is really just a vunerability of someone
writing a bad stomp client (when most folks use stomp and ActiveMQ
inside the firewall).
So rather than moaining about the sky falling; why don't you try fix
the one bug you have?
http://activemq.apache.org/contributing.html
Open source doesn't really work by moaning or spreading FUD about a
project; it works by contributing.
> A lot of the ActiveMQ components aren't merely buggy, but simply don't work.
Oh please.
> Authentication and security should be mandatory, but the ActiveMQ.Agent feature doesn't work if auth is enabled.
I'm not aware of any any MOM where authentication and security are
mandatory out of the box; its usually always something you configure
using whatever technologies you like.
> Neither does the Web Console queueBrowser. These components should be move to a sandbox.
Huh?
> There is pretty clear theme in the ActiveMQ development. Authentication and security are an afterthought. Like seriously an afterthought, as in after the release is cut.
>
> I'm amazed that ActiveMQ made it out of Apache incubation.
Thanks for those helpful comments Tom
--
James
-------
http://macstrac.blogspot.com/
Re: About releases and bugs
Posted by James Strachan <ja...@gmail.com>.
On 6/28/07, Manuel Teira <mt...@tid.es> wrote:
> Rob Davies escribió:
> > ActiveMQ is deployed and used in lots of different scenarios. Given
> > the breadth of the project, its very difficult for a few people to
> > cover everything - which is why we encourage folks to participate and
> > help us out ;)
> And we are willing to help.
> I know this is a complex and great project, and I assume the complexity
> that involves making it work perfectly for all the different scenarios
> and test cases. My post was not intended to reproach you for the bugs
> I've found, only to know the best way to proceed.
>
> As you can see, I'm only asking a pair of questions about how to
> identify some changes we would need to backport to 4.1.1, if no more
> releases of the 4.1.x are expected. I want to get involved but it's
> difficult without a little feedback.
Welcome! :)
We should do a 4.1.2 release for sure; there's already some useful
fixes in there already but please feel free to backport any 5.0 fixes
you like and we can apply them to the 4.1.x branch & release. Details
of how to submit a patch are here...
http://activemq.apache.org/contributing.html
Though there's also heaps of fixes already in 5.0 - so we should try
get that puppy out ASAP as there are so many things resolved there.
http://issues.apache.org/activemq/browse/AMQ?report=com.atlassian.jira.plugin.system.project:roadmap-panel
e.g. 133 issues resolved in 5.0 so far
--
James
-------
http://macstrac.blogspot.com/
Re: About releases and bugs
Posted by Manuel Teira <mt...@tid.es>.
Rob Davies escribió:
> ActiveMQ is deployed and used in lots of different scenarios. Given
> the breadth of the project, its very difficult for a few people to
> cover everything - which is why we encourage folks to participate and
> help us out ;)
And we are willing to help.
I know this is a complex and great project, and I assume the complexity
that involves making it work perfectly for all the different scenarios
and test cases. My post was not intended to reproach you for the bugs
I've found, only to know the best way to proceed.
As you can see, I'm only asking a pair of questions about how to
identify some changes we would need to backport to 4.1.1, if no more
releases of the 4.1.x are expected. I want to get involved but it's
difficult without a little feedback.
Best regards.
>
>
> On Jun 28, 2007, at 4:19 AM, Tom Samplonius wrote:
>
>>
>> I have to agree with most of this. ActiveMQ is a buggy as hell.
>>
>> In my testing, I'd have to say ActiveMQ 4.1.1 is completely
>> unusable in production. I'm told that it is used in production
>> somewhere, but I suspect the usage is extremely narrow. I'd like to
>> know what usage actually works. So if you are using ActiveMQ in
>> production, how are you using it?
>>
>> The show-stopping bugs in 4.1.1 are:
>>
>> - ActiveMQ loses unacked messages if a Stomp client disconnects
>> without an explicit DISCONNECT (fixed in 4.2-something)
>>
>> - Stomp server does not support authentication. It is completely
>> wide-open. And the default install has a Stomp listener running, so
>> ActiveMQ is wide open if you have Stomp enabled (there is an
>> unofficial patch, but I don't think this one will even be fixed in 5.0).
>>
>>
>> A lot of the ActiveMQ components aren't merely buggy, but simply
>> don't work. Authentication and security should be mandatory, but the
>> ActiveMQ.Agent feature doesn't work if auth is enabled. Neither does
>> the Web Console queueBrowser. These components should be move to a
>> sandbox.
>>
>> There is pretty clear theme in the ActiveMQ development.
>> Authentication and security are an afterthought. Like seriously an
>> afterthought, as in after the release is cut.
>>
>> I'm amazed that ActiveMQ made it out of Apache incubation.
>>
>>
>> ----- "Manuel Teira" <mt...@tid.es> wrote:
>>> Hello.
>>>
>>> I will try to outline briefly our situation as activemq users:
>>>
>>> We are embedding a 4.0.2 broker in our system. It is suffering some
>>> problems:
>>> - Memory leaks.
>>> - Locks trying to create or delete temporary queues (AMQ-1278). Still
>>>
>>> trying to reproduce it to verify this bug as fixed for us.
>>> - Inactivity exceptions in running channels, perhaps related with the
>>>
>>> leaks and the GC monopolizing the CPU time.
>>>
>>> We are in the process of migrating to activemq 4.1.1. In our tests, as
>>>
>>> I've commented in a previous mail, we have found that:
>>> - Memory leaks are still happening, at least while creating
>>> temporary
>>> queues and consumers (AMQ-1297)
>>>
>>> As this bug is a stopper for us, we tried, as it's usually
>>> recommended,
>>> with more recent snapshots, to see if the problems were fixed. So, we
>>>
>>> have found, using the more recent 5.0 snapshot:
>>> - The memory leaks seems to be fixed.
>>> - Already delete messages can be browsed using the JMX console
>>> (AMQ-1296)
>>> - Messages are (hardly ever, but happens) duplicated or not
>>> delivered.
>>> (AMQ-1295)
>>> - What seems random Inactivity exceptions in running and active
>>> channels. Perhaps related with AMQ-1146.
>>>
>>> So, my first question is about next releases. I think I've read
>>> somewere
>>> that there will be a 4.1.2 release. I suppose that generated from svn
>>>
>>> branches/activemq-4.1. However, a recent fix like the one for AMQ-1146
>>>
>>> (related with the inactivity IO exceptions), was not applied on this
>>> branch. So, what does this mean? That this bug won't be fixed in a
>>> future 4.1.x release? That there would be no more 4.1.x ?
>>>
>>> In the current situation, I think that the best release for us is
>>> 4.1.1,
>>> if we were able to fix the leakages (5.0 found bugs are stoppers for
>>> us). Any idea of what changes could have fixed that leakage? I've
>>> also
>>> started to inspect the source code of the project. I have to say
>>> that,
>>> at a first glance, it looks great, well-organized and very modular.
>>> But
>>> it's hard for a newcomer to understand the whole thing and to find out
>>>
>>> where the different pieces go. Is there any guide for developers that
>>>
>>> could ease the learning process ?
>>>
>>> Thanks, and best regards.
>>
>
>
Re: About releases and bugs
Posted by Rob Davies <ra...@gmail.com>.
ActiveMQ is deployed and used in lots of different scenarios. Given
the breadth of the project, its very difficult for a few people to
cover everything - which is why we encourage folks to participate and
help us out ;)
On Jun 28, 2007, at 4:19 AM, Tom Samplonius wrote:
>
> I have to agree with most of this. ActiveMQ is a buggy as hell.
>
> In my testing, I'd have to say ActiveMQ 4.1.1 is completely
> unusable in production. I'm told that it is used in production
> somewhere, but I suspect the usage is extremely narrow. I'd like
> to know what usage actually works. So if you are using ActiveMQ in
> production, how are you using it?
>
> The show-stopping bugs in 4.1.1 are:
>
> - ActiveMQ loses unacked messages if a Stomp client disconnects
> without an explicit DISCONNECT (fixed in 4.2-something)
>
> - Stomp server does not support authentication. It is completely
> wide-open. And the default install has a Stomp listener running,
> so ActiveMQ is wide open if you have Stomp enabled (there is an
> unofficial patch, but I don't think this one will even be fixed in
> 5.0).
>
>
> A lot of the ActiveMQ components aren't merely buggy, but simply
> don't work. Authentication and security should be mandatory, but
> the ActiveMQ.Agent feature doesn't work if auth is enabled.
> Neither does the Web Console queueBrowser. These components should
> be move to a sandbox.
>
> There is pretty clear theme in the ActiveMQ development.
> Authentication and security are an afterthought. Like seriously an
> afterthought, as in after the release is cut.
>
> I'm amazed that ActiveMQ made it out of Apache incubation.
>
>
> ----- "Manuel Teira" <mt...@tid.es> wrote:
>> Hello.
>>
>> I will try to outline briefly our situation as activemq users:
>>
>> We are embedding a 4.0.2 broker in our system. It is suffering some
>> problems:
>> - Memory leaks.
>> - Locks trying to create or delete temporary queues (AMQ-1278).
>> Still
>>
>> trying to reproduce it to verify this bug as fixed for us.
>> - Inactivity exceptions in running channels, perhaps related with
>> the
>>
>> leaks and the GC monopolizing the CPU time.
>>
>> We are in the process of migrating to activemq 4.1.1. In our
>> tests, as
>>
>> I've commented in a previous mail, we have found that:
>> - Memory leaks are still happening, at least while creating
>> temporary
>> queues and consumers (AMQ-1297)
>>
>> As this bug is a stopper for us, we tried, as it's usually
>> recommended,
>> with more recent snapshots, to see if the problems were fixed. So, we
>>
>> have found, using the more recent 5.0 snapshot:
>> - The memory leaks seems to be fixed.
>> - Already delete messages can be browsed using the JMX console
>> (AMQ-1296)
>> - Messages are (hardly ever, but happens) duplicated or not
>> delivered.
>> (AMQ-1295)
>> - What seems random Inactivity exceptions in running and active
>> channels. Perhaps related with AMQ-1146.
>>
>> So, my first question is about next releases. I think I've read
>> somewere
>> that there will be a 4.1.2 release. I suppose that generated from svn
>>
>> branches/activemq-4.1. However, a recent fix like the one for
>> AMQ-1146
>>
>> (related with the inactivity IO exceptions), was not applied on this
>> branch. So, what does this mean? That this bug won't be fixed in a
>> future 4.1.x release? That there would be no more 4.1.x ?
>>
>> In the current situation, I think that the best release for us is
>> 4.1.1,
>> if we were able to fix the leakages (5.0 found bugs are stoppers for
>> us). Any idea of what changes could have fixed that leakage? I've
>> also
>> started to inspect the source code of the project. I have to say
>> that,
>> at a first glance, it looks great, well-organized and very modular.
>> But
>> it's hard for a newcomer to understand the whole thing and to find
>> out
>>
>> where the different pieces go. Is there any guide for developers that
>>
>> could ease the learning process ?
>>
>> Thanks, and best regards.
>
Re: About releases and bugs
Posted by Tom Samplonius <to...@samplonius.org>.
I have to agree with most of this. ActiveMQ is a buggy as hell.
In my testing, I'd have to say ActiveMQ 4.1.1 is completely unusable in production. I'm told that it is used in production somewhere, but I suspect the usage is extremely narrow. I'd like to know what usage actually works. So if you are using ActiveMQ in production, how are you using it?
The show-stopping bugs in 4.1.1 are:
- ActiveMQ loses unacked messages if a Stomp client disconnects without an explicit DISCONNECT (fixed in 4.2-something)
- Stomp server does not support authentication. It is completely wide-open. And the default install has a Stomp listener running, so ActiveMQ is wide open if you have Stomp enabled (there is an unofficial patch, but I don't think this one will even be fixed in 5.0).
A lot of the ActiveMQ components aren't merely buggy, but simply don't work. Authentication and security should be mandatory, but the ActiveMQ.Agent feature doesn't work if auth is enabled. Neither does the Web Console queueBrowser. These components should be move to a sandbox.
There is pretty clear theme in the ActiveMQ development. Authentication and security are an afterthought. Like seriously an afterthought, as in after the release is cut.
I'm amazed that ActiveMQ made it out of Apache incubation.
----- "Manuel Teira" <mt...@tid.es> wrote:
> Hello.
>
> I will try to outline briefly our situation as activemq users:
>
> We are embedding a 4.0.2 broker in our system. It is suffering some
> problems:
> - Memory leaks.
> - Locks trying to create or delete temporary queues (AMQ-1278). Still
>
> trying to reproduce it to verify this bug as fixed for us.
> - Inactivity exceptions in running channels, perhaps related with the
>
> leaks and the GC monopolizing the CPU time.
>
> We are in the process of migrating to activemq 4.1.1. In our tests, as
>
> I've commented in a previous mail, we have found that:
> - Memory leaks are still happening, at least while creating
> temporary
> queues and consumers (AMQ-1297)
>
> As this bug is a stopper for us, we tried, as it's usually
> recommended,
> with more recent snapshots, to see if the problems were fixed. So, we
>
> have found, using the more recent 5.0 snapshot:
> - The memory leaks seems to be fixed.
> - Already delete messages can be browsed using the JMX console
> (AMQ-1296)
> - Messages are (hardly ever, but happens) duplicated or not
> delivered.
> (AMQ-1295)
> - What seems random Inactivity exceptions in running and active
> channels. Perhaps related with AMQ-1146.
>
> So, my first question is about next releases. I think I've read
> somewere
> that there will be a 4.1.2 release. I suppose that generated from svn
>
> branches/activemq-4.1. However, a recent fix like the one for AMQ-1146
>
> (related with the inactivity IO exceptions), was not applied on this
> branch. So, what does this mean? That this bug won't be fixed in a
> future 4.1.x release? That there would be no more 4.1.x ?
>
> In the current situation, I think that the best release for us is
> 4.1.1,
> if we were able to fix the leakages (5.0 found bugs are stoppers for
> us). Any idea of what changes could have fixed that leakage? I've
> also
> started to inspect the source code of the project. I have to say
> that,
> at a first glance, it looks great, well-organized and very modular.
> But
> it's hard for a newcomer to understand the whole thing and to find out
>
> where the different pieces go. Is there any guide for developers that
>
> could ease the learning process ?
>
> Thanks, and best regards.