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