dot.r Stomp announcement - Forum - OpenEdge Development - Progress Community
 Forum

dot.r Stomp announcement

  • jmls wrote:

    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

    myguid subscription.

    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

  • Hi Julian,

    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. 

  • Hi Julian,

    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!

    -peter

  • 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?

    Thanks,

    Paul.

  • 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

       heart-beat:0,60000

    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.