jmls wrote:In the meantime, we don't use temporary queues
In the meantime, we don't use temporary queues
That is probably not an option, as the other party is and NMS client that conforms to the rules http://blog.cylewitruk.com/2011/08/synchronous-request-response-messaging-with-nms-and-activemq/
right, but if the other party simply responds to the queue specified
in the reply-to header, then won't it get back to your abl client ?
ActiveMQ will only change the reply-to queue name if you specify
/temp-queue/yourqueue instead of /yourqueue/. If you specify
"reply-to: /myguid" then the nms client reply should be sent down the
There are settings in the ActiveMQ configuration to automatically
delete queues and topics that are no longer in use, something that
also helps provide temp-queue functionality
In the meantime, I'll let you know what I hear back
On 1 December 2012 20:21, Peter van Dam
The only way I could get this working was by officially creating a temporary queue in the broker.
I added the code below in StompClient.cls to achieve this.
I am happy now since this works fine so you might consider adding this to your code base.
METHOD PUBLIC CHARACTER SubscribeToTempQueue(): RETURN SubscribeToTemp("queue"). END. METHOD PUBLIC CHARACTER SubscribeToTempTopic(): RETURN SubscribeToTemp("topic"). END. METHOD PUBLIC CHARACTER SubscribeToTemp (p_type AS CHAR): DEFINE VARIABLE nfram# AS CHARACTER. DEFINE VARIABLE TempQueue AS CHARACTER. ASSIGN TempQueue = GUID(GENERATE-UUID). CREATE TTDestination. ASSIGN TTDestination.Destination = SUBSTITUTE("/temp-&1/ID:&2", p_type, TempQueue) TTDestination.ID = GUID(GENERATE-UUID). ASSIGN nfram# = SUBSTITUTE("SUBSCRIBE~nid:&1~ndestination:&2~nack:auto~n~n", TTDestination.ID,TTDestination.Destination). StompConnection:sendFrame(nfram#). RETURN TempQueue. END METHOD.
After an extensive investigation EMEA (kudos to Rob Debbage!) figured out that this is an OpenEdge bug that only hits you when you set -cpinternal UTF-8 -cpstream UTF-8 which I was doing in my test environment but luckily not (yet) in the production environment.
The issue is logged as bug# OE00230773.
Yeah, I got a message from Psc informing me that someone had logged this . Kudos, again, to Psc for letting me know.
And, I have to say, well done to you for finding this !
* jmls is just really glad it's not my code
Now I hope that you're finding it useful !
jmls wrote: Now I hope that you're finding it useful !
Definitely because now I know I can confidently put this code in production as long as we don't use UTF-8 which luckily is not the case.
I have noticed that the error had not occurred on the two pilot sites but could not explain that. Now I can.
Your code is excellent!
Keep up the good work!
your cheque is in the post ..
On 22 January 2013 21:20, Peter van Dam
Sorry for digging up an old post, but are there any examples with message selectors? also can the message selector be changed without starting a new session?
never them myself, but from these docs (activemq.apache.org/.../stomp-manual.html) all I think you need to do is add a header with the appropriate selector before you subscribe
> I have noticed that every morning the socket connection seems to have been lost overnight.
I know that this is far too late to be of any use to you -- but I thought I would add a comment for others who might find this on a search. We ran into a similar problem -- our connection to ActiveMQ would regularly hang for no obvious reason. What we found was this:
1) There was a state-aware firewall between the client and the server. A connection would be opened between the two, but after about 90 minutes the firewall would notice that there had been no traffic, and would drop the connection. Neither end was notified.
2) The ABL STOMP client system is installed on Cent/OS 7 system with the default TCP/IP configuration. That means that after 2 hours the TCP/IP stack noticed the lack of traffic. It would try to contact the remote system 10 times, separated by 75 seconds. Since the firewall had closed the connection, these attempts failed and the TCP/IP stack closed the local connection. Our ABL Stomp client was so informed, and it shut down.
This problem was resolved (in a manner of speaking) by adding
to the (hard-coded) connect frame. This tells the ActiveMQ system to send a heart-beat every minute, keeping the network connection alive.
I don't know what was happening on the ActiveMQ server at the same time -- but it never dropped the stale consumer from the queue. Heartbeats would probably resolve that issue too -- but that's a separate conversation.