SonicMQ adapter error handling - Forum - OpenEdge General - Progress Community

SonicMQ adapter error handling


SonicMQ adapter error handling

  • Hi,

    Does somebody have (good) experience with SonicMQ in combination with Progress V9.1E. I have noticed that SonicMQ isn't very stable working with Progress. When it's running then everything is OK. But what happens if Sonic is down. What happens if the SonicMQ adapter is down. Then you have to catch or handle the error.

    But progress doesn't seems to support this feature correctly. I have to wait (about) 5 minutes before you get an error????

    When you are running applications that are connecting with Sonic, it’s undesirable to wait so long. I have produced some scenario’s and getting the following problems:

    -         The agent of SonicMQ adapter are all busy L. I’m very sure I have used the deleteSession function correctly (don’t worry).

    -         In some cases getting the error JMS-MAXIMUM-MESSAGE error L . I’m very sure I have used the deleteMessage function correctly (don’t worry).

    Please don't answer to upgrade to OE if you don’t have a good answer, because everybody knows that you can’t upgrade directly. Besides in OE you still have the same problem I think?

    Ohh one more thing does somebody knows how you can establisch the Sonic Connection without disconnecting it. So I can reuse the connection without establisch it by every sending message. This will help the performance. Can you give some usefull 4gl code, I will appreciate it!

    Perhaps I’m doing something wrong?? Help! Thanx!



  • If you don't want to connect/reconnect all the time, just use a persistent procedure to manage your sonic communication:

    In v9 (could not find in v10) have a look at /src/samples/sonicmq/adapter/gateway_example.

    If you don't find it, we'll ask Progress to upload it (it's their source!).

    On how to detect you've dropped out of a JMS connection, consider the example on page 14-42 of the External Program Interfaces handbook (

  • Hi David,

    Thanks for you answers. I already have seen those examples. I'm not a Progress guru, but I was more thinking about some progress batches who are going to connect to the brokers instead of using them in my application? In my application I will invoke the running batch,.  I mostly need the request/reply mechanism. Do you have an example for that scenario or another?



  • The delay you are seeing is the socket connection timing out. Sockets are automatic retry until a limit is reached.I don't remember if setInitialConnectionTimeout is part of the V9 adapter.

  • Please don't answer to upgrade to OE if you don’t have a good answer, because everybody knows that you can’t upgrade directly. Besides in OE you still have the same problem I think?

    I know it isn't the answer you want to hear, but the interaction between ABL and Sonic has been enhanced substantially over the successive OE10 releases so you really are trying to paddly your canoe with a tablespoon by sticking with 9.1E.  And, I don't know what you mean by "everybody knows that you can't upgrade directly" since this part of everybody and a whole lot of others would tell you the exact opposite.  99.9% of the time the only real obstacle to upgrading is a stupid VAR who can't seem to figure out that it is in his interest to enable people to keep current on Progress versions and insists that an older version of their software is only supported on an older version of Progress.  The issue there is not a technical barrier, but simply a question of the VAR being too lazy or cheap to test an old version of their software on a new version of Progress and not wanting to support something they haven't tested.  Of course, the seed of this problem is not having constructed their application in a way that makes it easy for the end-user to customize withou then creating a barrier to upgrading to current releases.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice