RE: Persistent Messaging Questions

Ken,
 
We also experienced the same problem as have others on this list.  I never
tried using the publish method without the extra args.  It's interesting
that it gives you a different result.  Anyway, we never received a
satisfactory response and have switched to JBossMQ which works very well.
 
-Mark
 
 
-----Original Message-----
From: Ken M [mailto:wgold-WNUMbkg7HQH83n0zhJamUgC/[email protected]] 
Sent: Monday, May 09, 2005 6:30 PM
To: [email protected]
Subject: Re: [openjms-user] 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 <mailto:wgold-WNUMbkg7HQEU2wQfUptkSQ0oxQXmrEhyAL8bYrjMMd8@public.gmane.org>