Re: Persistent Messaging Questions

More information if it helps:

The symptom of lost messages occurs if I use ANY value for TTL.  I've 
tried from 1 to 300000 (in random increments :) and the lowend-CPU 
clients consistently drop nearly 25% of the messages that are sent in 
rapid succession. 

Maybe there's a thread pooling issue? Should I increase a pool parameter?

Please Advise

Ken M.

P.S.:  Can anyone hint a quicjk and easy way to turn DEBUGGING on?  Our 
app doesn't use commons-logging in general.



Ken M wrote:

> 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