activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From fenbers <Mark.Fenb...@noaa.gov>
Subject Re: The dilemma of not acknowledging messages
Date Mon, 13 Aug 2012 10:26:30 GMT

  
    
  
  
    Torsten, 
    
    Thank you for your response.&nbsp; For your background, in my
    application, the messages consist of indicators of the status of
    progress toward a certain end state.&nbsp; My app just lights up buttons
    in various colors depending on the status messages received.&nbsp; Thus,
    in a strop and restart situation, the indicators are blank (unlit)
    for (possibly) a long while until&nbsp; new messages are received.&nbsp; This
    is why I wanted messages redelivered. 
    
    However, Raul, Kripalani has pointed out in a similar thread that
    ActiveMQ has a "Recovery Policy" that can be setup to allow message
    redelivery for this kind of situation.&nbsp; So this is the solution that
    I had been hoping for... that I can acknowledge messages, and yet
    still get them redelivered upon client restart (up to a certain
    amount of time or disk space).&nbsp; 
    
    Mark 
    
    On 8/13/2012 3:52 AM, Torsten Mielke-2
      [via ActiveMQ] wrote: 
    
     Hello Mark,
      
      
      You do have to acknowledge messages that you consume in your JMS
      clients.
      
      There is no way you can run a broker reliably over a longer period
      of time without ever acking any consumed messages.
      
      As you already observe, the brokers journal files will be piling
      up and I would not be surprised if you get into other side affects
      because of that.
      
      
      A JMS broker's job is to move accept messages from a producer and
      pass them to a or more consumers.
      
      Its the duty of the consumer to ack any messages it has processed.
      
      If you don't ack the messages and if your consumer disconnects and
      reconnects, your messages will be redelivered and thus be
      processed twice. You generally don't want this behavior. 
      But bottom line is it is wrong to not ack any messages that have
      been processed successfully in your clients. 
      
      I don't understand the reasoning why you don't want to ack msgs
      after they got processed by your consumers, but I am fairly sure
      you need to find a different approach than not acking msgs. 
      Also, I cannot suggest deleting any of the brokers journal files
      manually while the broker is running. I presume this could corrupt
      the persistence adapter entirely. 
      
      For whatever your requirements are, find a different solution than
      not acking the consumed msgs. 
      (e.g. if you need to process some messages again at a later point
      in time, perhaps store these msgs in a dedicated area of a
      database and have some other app process this db table and
      resubmit these messages to the broker if necessary?)
      
      
      
      
      Torsten Mielke
      
      [hidden email] 
      
      [hidden email] 
      
      
      
      
      
      &nbsp;
      
      On Aug 9, 2012, at 8:17 PM, fenbers wrote:
      
      
        &gt; Greetings!
        
        &gt; 
        &gt; I want unexpired JMS messages to be redelivered if my
        client application is
        
        &gt; stopped and restarted. &nbsp;To accomplish this, I do not have
        the client
        
        &gt; acknowledge the receipt of messages. &nbsp;An unfortunate
        side-effect of this
        
        &gt; practice is that the db-/N/.log files in the
        ${activemq.data}/kahadb
        
        &gt; directory never get cleaned up, and after these build up to
        a few hundred in
        
        &gt; number, ActiveMQ starts affecting the performance of it
        clients (although I
        
        &gt; cannot yet tell if it is the producer part that's bogging
        down or the
        
        &gt; consumer part that's bogging down). &nbsp;I did add &nbsp;to
        activemq.xml, but
        
        &gt; commented out &nbsp;and don't remember why, but this did cause
        some sort of
        
        &gt; problem when I last tried it over a year ago...
        
        &gt; 
        &gt; As I see it, there are three ways to get around this
        problem. &nbsp;I don't know
        
        &gt; if any of them are possible, and is what I am seeking
        advice about. &nbsp;They
        
        &gt; are:
        
        &gt; 1) figure out a way to have unexpired messages redelivered
        even if they've
        
        &gt; been acknowledged.
        
        &gt; 2) figure out a way to have the delivered (but expired)
        messages purged even
        
        &gt; though they haven't been acknowledged by the client.
        &nbsp;(Currently, if they
        
        &gt; are not acknowledged, they are marked "in-use" and the
        db-/N/.log files
        
        &gt; aren't cleaned up.)
        
        &gt; 3) occasionally delete the older db-/N/.log outside of
        ActiveMQ (say on
        
        &gt; cron, etc.), but will this cause ActiveMQ to behave
        improperly?
        
        &gt; 
        &gt; Or is there a different way altogether?
        
        &gt; 
        &gt; Mark
        
        &gt; 
        &gt; 
        &gt; 
        &gt; --
        
        &gt; View this message in context: http://activemq.2283324.n4.nabble.com/The-dilemma-of-not-acknowledging-messages-tp4654973.html

        &gt; Sent from the ActiveMQ - User mailing list archive at
        Nabble.com.
      
      
      
      
      
      
        If you reply to this email, your
          message will be added to the discussion below: 
        http://activemq.2283324.n4.nabble.com/The-dilemma-of-not-acknowledging-messages-tp4654973p4655038.html

      
      
        To unsubscribe from The dilemma of not acknowledging messages, click
          here . 
        NAML  
    
    
  





--
View this message in context: http://activemq.2283324.n4.nabble.com/The-dilemma-of-not-acknowledging-messages-tp4654973p4655043.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message