RE: Persistent Messaging Questions

I suspect you're running in to the following bug:
http://sourceforge.net/tracker/index.php?func=detail
<http://sourceforge.net/tracker/index.php?func=detail&aid=1165743&group_id=5
4559&atid=474136> &aid=1165743&group_id=54559&atid=474136
 
In answer to your questions:
1. The purgeMessage() method no longer is relevant, as the server (with the
exception of the above bug)
    removes messages as they are processed. 
 
2. Related to the above bug. In 0.7.6.x it only gets updated for durable
subscriptions. 
 
3. You can't set the JMSExpiration property on the message, as it gets
overriden by the publish() 
    method on send.
    You need the TopicPublisher.publish(Message message, int deliveryMode,
int priority, long timeToLive) 
    method.
 
4. Possibly due to a system clock mismatch beween the client and server
hosts.
    The expiration time is an absolute time expressed in milliseconds (i.e
the JMSExpiration message property), 
    and is determined in the client
    However, the server is responsble for expiring messages. If the server
host's clock is advanced relative 
    to the client's, then messages will expire sooner.
 
    Can you verify that this is the case? If so I'll look at putting a fix
in for 0.7.7.
 
-Tim
 

-----Original Message-----
From: openjms-user-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
[mailto:openjms-user-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of Ken M
Sent: Tuesday, 10 May 2005 5:33 AM
To: OpenJMS User
Subject: [openjms-user] Persistent Messaging Questions


Hey guys - 

I've run into a couple of issues that I hope you can help with.

1) JmsAdminServerIfc.purgeMessages() -- Is deprecated, no replacement, and
never works (using Sybase as the RDBMS).  It always returns (0).  This could
be in response to the next issues I'm seeing.

2) In the RDBMS message store, the messages are always marked as "processed:
0" -- unprocessed?  Even if I call "message.acknowledge()" (Is this even the
right thing to do?) 

I haven't dug through the code yet, but it seems that if my non-durable
subscribers on an AdministeredTopic have all onMessage(), acknowledged() and
moved on - the message should be "processed" yes?  This column is always 0.


3) Before sending the message, I call message.setJMSExpiration() -- yet the
DB never has anything in the "expiryTime" field.  It's always "0".

Here's how I Send the mesages:

               SimpleMessage message = new SimpleMessage( someData );
               Message m = topicSession.createObjectMessage(message);
               m.setJMSExpiration(System.currentTimeMillis() + 60000);
               systemTopicPublisher.publish( m );


Also - 
4)  The issue we originally started working on was that our system runs for
weeks at a time under moderate message load. (100 - 200 messages/minute).
This would cause our DB to grow in size until it would overgrow our
filesystem and crash the application.  After running into the problem of not
being able to "purge" messages, we decided to use NON_PERSISTENT messages.
The thought was that if our subscriber wasn't alive, so what;  He wouldn't
get the message - that seemed fine.. Except that JMS started losing messages
from certain low-CPU clients.  I mean LOSING them, we see the message
prepared and go out on the client, but the server never gets it.  The
failure rate is approximately 25%.  The change was minimal, but this was the
publish line:

               systemTopicPublisher.publish( m, DeliveryMode.NON_PERSISTENT,
4, 30000);

Which, IIRC, says "Publish this to any living subscribers, NON_PERSISTENTly,
Priority 4 (default from what the docs say) - and a TTL value of 30
seconds." 

30 seconds is FAR AND BEYOND what is required to deliver any of these
messages we send.  Even on a low CPU (<800MHz) machine, we see an average of
50-100ms times (non-persistent) and 400-500ms persistent.  What I don't
comprehend is how using publish(m) vs publish(m, NP, 4, 30000) can cause the
JMS server to lose messages.  I've tested this over and over and over again
and the facts remain the same.. I've even tried using:

               systemTopicPublisher.publish( m, DeliveryMode.PERSISTENT, 4,
30000);

We changed the mode to PERSISTENT thinking that they were being dropped...
This line produced no difference, 1 in 4 of the messages from the low-CPU
machine were dropped on the floor somewhere.  It always seems that when 4
messages go out quickly, the 4th is lost.

So - here I am now.. I've reset the system to use PERSISTENT messages,
trimmed the publish line back to the default "publish(m)" and all client's
messages are now being delivered as expected.  Since I can't seem to set a
TTL or ExpiryTime that sticks, or call "purgeMessages()" this leaves me with
a system that is bloated, and getting more bloated every second under usage.
I can NOT stop the server to re-start and let the system clean itself up..
This is a real world system that MUST run 24/7.

Help?

Ken Melms
wgold-WNUMbkg7HQEU2wQfUptkSQ0oxQXmrEhyAL8bYrjMMd8@public.gmane.org