Re: Latency during send

We experienced odd timings wher we used PERSISTENT messages.  We tried 
everything to fix our startup and message latency issues.

In the end, we needed persistence, but created a worker thread to purge 
old messages from the system (something, IME, OpenJMS should do 
itself).  Once we did this, the system was flying fast and easy again.  
The key was to find the messages older than a certain time and remove 
them from the system.  IME, OpenJMS doesn't set messages as "processed".

The code I used to purge messages isn't pretty, as it relies on internal 
exolab classes, but here it is:

         Timer purgeTimer = new Timer();
         TimerTask purgeTask = new TimerTask(){
            public void run()
            {
               try
               {
                  long now = System.currentTimeMillis();
                  logger.log(Level.INFO, "Purging old JMS Messages");
                  java.sql.Connection c = DatabaseService.getConnection();
                  Messages m = Messages.instance();

                  Vector v = m.getUnprocessedMessages(c);

                  int x = 0;
                  for (Enumeration e = v.elements(); e.hasMoreElements(); )
                  {
                     Message mm = (Message)e.nextElement();

                     long time = mm.getJMSTimestamp();

                     // 30 minutes.
                     if (time < (now - 1800000))
                     {
                        m.remove(c, mm.getJMSMessageID());
                        x++;
                     }
                  }
                  c.commit();
                  SQLHelper.close(c);
                  logger.log(Level.INFO, "Purged " + x + " retired 
messages.");

               }
               catch (PersistenceException e)
               {
                  logger.log(Level.SEVERE, "Can't complete.", e);
               }
               catch (JMSException e)
               {
                  logger.log(Level.SEVERE, "Can't complete.", e);
               }
               catch (SQLException e)
               {
                  logger.log(Level.SEVERE, "Can't complete.", e);
               }
            };

         };

         logger.log(Level.INFO, "Purging messages every 60 seconds.");
         purgeTimer.schedule( purgeTask, 0, 60000);




Rebecca Witmer wrote:

> I'm working on an app using OpenJMS to send a bunch of messages all at 
> once and I'm experiencing some bizarre intermittent latency.  Last 
> week the app started slowing down and leaving a ~20 second gap while 
> it sent 24 messages.  We messed with various things, took some things 
> up and down, restarted the machine and magically the latency 
> disappeared.  It worked fine all last week but yesterday the latency 
> came back.  At first it was 8 seconds, then 12 then 16 or so.  At this 
> point it's taking about 500-600 ms to send a message.  We've 
> eliminated all the extraneous code and tested the timing with a simple 
> message sending class.  The timing is consistent.  We tried moving the 
> code to a faster  machine but the send still took at least 100 ms.  I 
> searched the archives of the forum and found a few posts on latency 
> but not a lot comes up in the way of answers as to what can cause it.  
> Several people has the same problem I am having, though.  That's not 
> consistent with the estimates I read that indicate that OpenJMS can 
> send hundreds of messages per second.
>
> At this point we're considering restructuring the app to send all the 
> data it needs to send in one large conglomerate message rather than 24 
> or so small ones.  It seems that that might work faster.  Does anyone 
> agree?  Does anyone have any thoughts as to what can cause 
> intermittent latency that worsens over time like that?  We've tried to 
> eliminate potential problems in the operating environment one at a 
> time but nothing seems to change anything.
>
> Baffled.  Any thoughts are much appreciated.
>
> Thanks.



-- 
----

The cause of America is, in a great measure, the cause of all mankind. Many circumstances have, and will arise, which are not local, but universal, and through which the principles of all lovers of mankind are affected, and in the event of which, their affections are interested. The laying a country desolate with fire and sword, declaring war against the natural rights of all mankind, and extirpating the defenders thereof from the face of the earth, is the concern of every man to whom nature hath given the power of feeling; of which class, regardless of party censure, is

The author.
Philadelphia, Feb. 14, 1776.



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf