Re: 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&aid=1165743&group_id=54559&atid=474136 
> <http://sourceforge.net/tracker/index.php?func=detail&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
>