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.