I agree with Todd: a key is to keep the client unaware of the mux existence.
So the same client can be run on system without the cache.
Hal Rosenstock wrote:
On Fri, 2006-01-06 at 09:05, Rimmer, Todd wrote:
From: Hal Rosenstock [mailto:[EMAIL PROTECTED]
On Thu, 2006-01-05 at 18:36, Rimmer, Todd wrote:
This of course implies the "SA Mux" must analyze more than just
the attribute ID to determine if the replica can handle the query.
But the memory savings is well worth the extra level of filtering.
If the SA cache does this, it seems it would be pretty simple
to return
this info in an attribute to the client so the client would
know when to
go to the cache/replica and when to go direct to the SA in the case
where only certain queries are supported. Wouldn't this be
advantageous
when the replica doesn't support all queries ?
Why put the burden on the application. give the query to the Mux.
That's what I'm suggesting. Rather than a binary switch mux, a more
granular one which determines how to route the outgoing SA request.
With an optional flag indicating a prefered "routing" (choices of: to SA,
to replica, let Mux decide). Then let it decide. As you suggest it may
be simplest to let the Mux try the replica and on failure fallback
to the SA transparent to the app (sort of the way SDP intercepts
socket ops and falls back to TCP/IP when SDP isn't appropriate).
It depends on whether the replica/cache forwards unsupported requests on
or responds with not supported back to the client as to how this is
handled. Sean was proposing the forward on model and a binary switch at
the client. I think this is more granular and can be mux'd only with the
knowledge of what a replica/cache supports (not sure about dealing with
different replica/caches supporting a different set of queries; need to
think more on how the caches are located, etc.). You are mentioning a
third model here.
-- Hal
_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
