Christian Haul wrote:
On 13.Oct.2003 -- 03:02 PM, Geoff Howard wrote:
- Durable subscription handling.
I think we need "at least once" semantics to avoid delivering dirty caches. I've seen durable connections mentioned in conjunction with subscribers that are offline. Cocoon shutting down would invalidate caches anyway (and other program state), so is this really needed?
Cocoon persists caches if configured to use persistent store (and if jetty is not used at least as configured in the bundled version). So between that and network loss and reconnection, I've always thought durable subscriptions would turn out to be crucial.
Oh yes! I tend to forget these things :-| Sure, this requires persistent delivery.
Generally, I've thought the eventcache needs to be "fail fast" in the sense that if it encounters a condition that reveals that any events may have been missed the entire cache (or at least anything with Event based validity) needs to be invalidated.
Right.
About your idead of sending content with the messages -- at least if we are talking about caches it is probably too difficult to use this data to update the cache. But maybe we could re-request the same request that filled the cache before? Or is that hashed into the cache key and can't be reconstructed? OTOH doing that pro-actively could cause additional load at high times... Not sure about this.
OK, I've put the sample in a new JMS block and created an action that could send JMS messages. There's a JMSConnection (bad name) that holds connection properties and instantiates a connection + session.
Ok, I'll check this out. When I went back to look at the JMS block on my HDD it was much thinner than I remembered it. I'm sure I'll be able to factor anything it offerred in to what you've got now.
Don't hesitate to dump things as you see fit. I assume you know a lot more about practical JMS than I do :-) (haven't *really* used JMS before)
Chris.
--
C h r i s t i a n H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08