Geoff Howard wrote:
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.
I think your scenario is right (that it would be difficult or impossible to re-fill the cache from an event data) but in discussion before on this others have always expressed this as a desire and I haven't thought carefully enough whether it would really be all that bad. Still, the point remains that different people will have different needs for interpreting the received Message (perhaps some back-end system already has some default message subclass that they'd rather not change) and it seems that encapsulating that process is a smart move.
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)
I'm no expert but two heads are always better than one.
Geoff
