RE: Persistent Messaging Questions

-----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: Wednesday, 11 May 2005 1:59 AM
To: [email protected]
Subject: Re: [openjms-user] Persistent Messaging Questions



Tim - 

Thanks for the quick response!

Re #1: I had searched for related bugs, but must have missed that one.
Thanks for the link - good to know it's a known and resolvable issue.
Making our subscribers durable isn't really an option though.  We have One
"Server" and 1-N clients that will connect to consume and produce messages.
These clients are applets running in a browser somewhere on the network - so
making them durable isn't doable.  What if I removed the "AdministeredTopic"
configuration and just created the topic on server launch?  Would that have
any significant downside?  I don't want it to relax into NON_PERSISTENT
mode, otherwise the other bug I mentioned crops up - so I need to find a
path that works.
 
 
 
Re #2: Understood..  What if there was at least one configured durable
subscriber with 1-N non-durable subs?  Would that do it?

Re #3: I figured that out when I cracked open the publish() code.  That's
how I determined that ANY TTL was causing my message drops.

Re #4: The clocks are definitely mismatched.  The client clock was set 5
minutes earlier than the server.  We don't have direct control over the
client clocks though, so any fixes in there you can do would be greatly
appreciated!

Thanks again for your hard work and quick responses!  I know we, as a
community, have a tendency to forget to say that..

Peace -

K


Tim Anderson wrote: 

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