D
dbeavon
Guest
This is huge for us. Thanks for adding the note. Even if a customer continues to use Sonic MQ, the fact that we have other options helps during contract negotiations every three years. 
Otherwise OE customers are basically locked-in with "Aurea". I tried this out with Active MQ and was very pleased. I think Active MQ looks like a fairly robust product and it has options for using a real RDBMS for the message storage. It may not match Sonic MQ on performance but it has a very large number of features, is actively enhanced, and the price is right. Thanks, David PS. One thing I wanted to point out about my testing is that I initially had a bit of trouble with "client-connect" mode. The generic adapter was not initially going to be supported in that mode, but I think that has been changed now. The reasoning for not supporting it (as I recall) was that the generic adapter doesn't supply all of the features as Sonic MQ does in "client-connect" mode (eg. local client persisntence) and therefore that mode wasn't needed. However for us "client-connect" is a much better choice than "broker-connect", and it is for reasons that go well beyond the feature set of the JMS client. (IE. It is less complex, and more reliable because a failure in the adapter for one ABL process doesn't necessarily impact anyone else.) Of course the trade-off is that there are going to be tons of not-so-small java processes (aka "symbionts") which are launched whenever an ABL program needs to do messaging. (Only about half of our _progres clients do JMS messaging)
Continue reading...
Otherwise OE customers are basically locked-in with "Aurea". I tried this out with Active MQ and was very pleased. I think Active MQ looks like a fairly robust product and it has options for using a real RDBMS for the message storage. It may not match Sonic MQ on performance but it has a very large number of features, is actively enhanced, and the price is right. Thanks, David PS. One thing I wanted to point out about my testing is that I initially had a bit of trouble with "client-connect" mode. The generic adapter was not initially going to be supported in that mode, but I think that has been changed now. The reasoning for not supporting it (as I recall) was that the generic adapter doesn't supply all of the features as Sonic MQ does in "client-connect" mode (eg. local client persisntence) and therefore that mode wasn't needed. However for us "client-connect" is a much better choice than "broker-connect", and it is for reasons that go well beyond the feature set of the JMS client. (IE. It is less complex, and more reliable because a failure in the adapter for one ABL process doesn't necessarily impact anyone else.) Of course the trade-off is that there are going to be tons of not-so-small java processes (aka "symbionts") which are launched whenever an ABL program needs to do messaging. (Only about half of our _progres clients do JMS messaging)Continue reading...