RE: Persistent Messaging Questions

"Tim Anderson" <[email protected]>
Newsgroups gmane.comp.java.openjms.user
Message-ID <004b01c556fd$9b2672b0$7c7bfddc@xerces>
Ignore that last response. Bit trigger happy.
See inline.
 
-----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. 
 
If the topic isn't administered, it is therefore non-persistent, so all
messages are treated as
 having NON_PERSISTENT delivery mode. Not what you're after.
 
Re #2: Understood..  What if there was at least one configured durable
subscriber with 1-N non-durable subs?  Would that do it? 
Might work. Sorry - not in a position to verify at the moment.   

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. 
Actually, its any TTL which is less than the maximum difference between
client and server clocks.
Had you picked a TTL greater than that difference, they wouldn't have
appeared to have been lost . 

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!
 
I'll keep you posted.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.