From 5b93313da166559fa944178bfd1775eb08c7995c Mon Sep 17 00:00:00 2001 From: Mike Taylor Date: Wed, 3 May 2006 13:33:22 +0000 Subject: [PATCH] Describe how MULTI works in combination with VIRT_DB --- doc/book.xml | 36 ++++++++++++++++++++++++++++++++---- 1 file changed, 32 insertions(+), 4 deletions(-) diff --git a/doc/book.xml b/doc/book.xml index d3437a8..3faf161 100644 --- a/doc/book.xml +++ b/doc/book.xml @@ -1,4 +1,4 @@ - + Metaproxy - User's Guide and Reference @@ -1254,9 +1254,37 @@ Z> through it. - ### Describe the use of multiple VAL_PROXY - otherInfos, added by virt_db and used by - multi. + It is possible for a virt_db filter to contain + multiple + <target> + elements. What does this mean? Only that the filter will add + multiple VAL_PROXY otherInfo packets to the + search requests that pass through it. That's because the virtual + DB filter is dumb, and does exactly what it's told - no more, no + less. + + + If a search request with multiple VAL_PROXY + otherInfo packets reaches a z3950_client + filter, this is an error. That filter doesn't know how to deal + with multiple targets, so it will either just pick one and search + in it, or (better) fail with an error message. + + + The multi filter comes to the rescue! This is + the only filter that knows how to deal with multiple + VAL_PROXY otherInfo packets, and it does so by + making multiple copies of the entire search-request: one for each + VAL_PROXY. Each of these new copies is then + passed down through the remaining filters in the route, instead of + the original one. (The copies are handled in parallel though the + spawning of new threads.) Since the copies each have ony one + VAL_PROXY otherInfo, they can be handled by the + z3950_client filter, which happily deals with + each one individually. When the results of the individual + searches come back up to the multi filter, it + merges them into a single search-response, which is what + eventually makes it back to the client. -- 1.7.10.4