Dan,
Some implementations provide both fault tolerance and durability.
The one I use, for example, allows read-through / write-behind
persistence to a database to address exactly the problem you note.
The vast majority of messages are picked up from memory, with a few
requiring the additional latency of a database access.
Regards,
Patrick
On 8 Dec 2008, at 04:20, Udi Dahan wrote:
Patrick,
Actually, javaspaces provide fault tolerance via replication instead
of durability, but, ok.
I’m quite familiar with using these kinds of technologies in
scenarios similar to that which I outlined in my blog post and there
are other issues that aren’t magically handled by the space, still
requiring solutions like those I outlined.
For instance, when a publisher puts a message/event into the space,
how long of a lease should it have? Too long and you may run out of
memory in the space, too little and subscribers that were
unavailable can miss it. That being said, these memory based
solutions can be much more performant than disk based solutions.
Thanks,
--
Udi Dahan - The Software Simplist
From: [email protected] [mailto:[email protected]
] On Behalf OfPatrick May
Sent: 07 December 2008 16:32
To: [email protected]
Subject: Re: [service-orientated-architecture] Re: Roch Clarifies
Some Key Terms
There is an alternative to implementing durable
subscribers by persisting messages to disk for each subscriber. A
JavaSpace provides durability in-memory, with each message stored
only once. Publishers and subscribers can join and leave at any
time without the need for complex coordination.
I'll refrain from advertising on Gervas' list, but I
work for a company that sells a distributed, highly available space
implementation that is interoperable across multiple languages. It
is frequently used to address exactly the issues you mention in your
blog post.
Regards,
Patrick
--
http://www.spe.com/pjm
On 7 Dec 2008, at 05:02, Udi Dahan wrote:
I’ve put a short article up on my blog about the whole issue of lost
notifications and pub/sub.
Lost Notifications? No Problem.
In it I outline how the various performance and availability
characteristics of different services may cause a subscriber to miss
a notification and how to feed that back into the design process to
get a service ecosystem where notifications (different kinds than
before) won’t be lost or missed.
Interested in hearing feedback, especially on how this may impact
the issues of monitoring and management Rob raised below.
--
Udi Dahan - The Software Simplist
From: [email protected] [mailto:[email protected]
] On Behalf OfRob Eamon
Sent: 05 December 2008 19:34
To: [email protected]
Subject: [service-orientated-architecture] Re: Roch Clarifies Some
Key Terms
--- In [email protected], "Udi Dahan"
<[EMAIL PROTECTED]> wrote:
>
>
> However, I'd assert that there are advantages to a pub/sub approach
> over a non-pub/sub approach, not the least being that additional
> subscribers can be added into the ecosystem without changes to pre-
> existing members.
That is a value of pub/sub, one that I think is touted well beyond
its actual benefit. It is indeed relatively easy to add a new
subscriber. What is less easy, and rarely mentioned, is the
additional work that is usually needed to monitor and manage that new
connection.
Pub/sub works best in a fire and forget mode--where publishers don't
care if the message makes it. IME, many publishers care very much
that the message gets to the intended recipients. Most business
solutions don't lend themselves to "I don't care if the message
doesn't make it." So one ends up creating elaborate monitoring and
retry facilities to tend to the pub/sub garden.
I'd argue that the bulk of solutions implemented over pub/sub rarely
if ever change the subscribing members. 1 publisher. 1-3 subscribers
that don't change. So we introduce a flexible (and more complex)
solution approach that needs neither.
> The crux is, IMO, what is the semantic thing that you are pub/sub-
> ing?
Agreed. IMO, pub/sub is for things where: 1) publishers/process
really don't care who is subscribing, nor if the messages get lost
now and then (which is more or less the problem Ranadive and others
addressed when they created TIB); 2) the subscribers change from time
to time.
IMO and IME, those two criteria (relatively) rarely exist in business
oriented systems.
> If the thing represents a command (imperative, present tense) like
> place order, bill customer, etc, I'd say that pub/sub is a poor
> solution.
I more or less agree, but I'm of the opinion that pub/sub is a poor
solution in more situations than others tend to believe.
-Rob
No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.176 / Virus Database: 270.9.13/1826 - Release Date:
05/12/2008 09:57
No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.176 / Virus Database: 270.9.13/1826 - Release Date:
06/12/2008 16:55
----
[EMAIL PROTECTED]
S P Engineering, Inc.
Large scale, mission-critical, distributed OO systems design and
implementation.
(C++, Java, Common Lisp, Jini, middleware, SOA)
