Re: Persistent Messaging Questions

-

Now if JBoss would just start minimizing it's use of configuration xml...
It's a terrible pain in the toucan..

K

Priest, Mark wrote:

> 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
>
>