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
