From 7668fcb6667ad2d108879de743b3d7a3ce8907a2 Mon Sep 17 00:00:00 2001
From: Kristian Aune Deploying a Document Processor
For example, the route default/chain.my-chain indexing
would route feed operations
through the chain "my-chain" in the "default" container cluster, and then to the "indexing" hop,
which resolves to the specified indexing chain for each content cluster the document should be sent to.
- More details can be found in indexing:
+ More details can be found in indexing:
-Indexing is the process of routing document writes to indexing processors, -processing (indexing) documents and writing the documents to content clusters. -
-Refer to the overview. -The primary index configuration is the schema. -services.xml configures how indexing is distributed to the nodes. -
-This article documents the default indexing, how to configure indexing for different clusters -and how to add custom document processing. -
-See #13193 -for a discussion on using default as a name. -
- -document-processing is an example of custom document processing, and useful for testing routing. -
- - - -- A normal Vespa configuration has container and content cluster(s), - with one or more document types defined in schemas. - Routing document writes means routing documents to the indexing container cluster, - then the right content cluster. + Indexing is the process of routing + document writes to indexing processors, + processing (indexing) documents and writing the documents to content clusters.
- The indexing cluster is a container cluster - - see multiple container clusters for variants. - Add the document-api - feed endpoint to this cluster. - The mapping from document type to content cluster is in - document in the content cluster. - From - album-recommendation: + Refer to the overview. + The primary index configuration is the schema. + services.xml configures how indexing is distributed to the nodes.
--<services version="1.0"> - - <container id="container" version="1.0"> - <document-api /> - <search /> - <nodes> - <node hostalias="node1" /> - </nodes> - </container> - - <content id="music" version="1.0"> - <redundancy>1</redundancy> - <documents> - <document type="music" mode="index" /> - </documents> - <nodes> - <node hostalias="node1" distribution-key="0" /> - </nodes> - </content> - -</services> --
-Given this configuration, Vespa knows which is the container cluster used for indexing, -and which content cluster that stores the music document type. -Use vespa-route -to display routing generated from this configuration: -
--$ vespa-route -There are 6 route(s): - 1. default - 2. default-get - 3. music - 4. music-direct - 5. music-index - 6. storage/cluster.music - -There are 2 hop(s): - 1. container/chain.indexing - 2. indexing -
-Note the default route. This route is auto-generated by Vespa, -and is used when no other route is used when using /document/v1. -default points to indexing: + This article documents the default indexing, how to configure indexing for different clusters + and how to add custom document processing.
--$ vespa-route --route default -The route 'default' has 1 hop(s): - 1. indexing --
-$ vespa-route --hop indexing -The hop 'indexing' has selector: - [DocumentRouteSelector] -And 1 recipient(s): - 1. music --
-$ vespa-route --route music -The route 'music' has 1 hop(s): - 1. [MessageType:music] -
-In short, the default route handles documents of type music. -Vespa will route to the container cluster with document-api - -note the chain.indexing above. -This is a set of built-in document processors that does the indexing (below). -
-Refer to the trace appendix for routing details. + See #13193 + for a discussion on using default as a name.
- - - -
-This indexing chain is set up on the container once a content cluster has mode="index"
.
-
-The -IndexingProcessor -annotates the document based on the indexing script -generated from the schema. Example: + + document-processing is an example of custom document processing, and useful for testing routing.
--$ vespa-get-config -n vespa.configdefinition.ilscripts \ - -i container/docprocchains/chain/indexing/component/com.yahoo.docprocs.indexing.IndexingProcessor - -maxtermoccurrences 100 -fieldmatchmaxlength 1000000 -ilscript[0].doctype "music" -ilscript[0].docfield[0] "artist" -ilscript[0].docfield[1] "artistId" -ilscript[0].docfield[2] "title" -ilscript[0].docfield[3] "album" -ilscript[0].docfield[4] "duration" -ilscript[0].docfield[5] "year" -ilscript[0].docfield[6] "popularity" -ilscript[0].content[0] "clear_state | guard { input artist | tokenize normalize stem:"BEST" | summary artist | index artist; }" -ilscript[0].content[1] "clear_state | guard { input artistId | summary artistId | attribute artistId; }" -ilscript[0].content[2] "clear_state | guard { input title | tokenize normalize stem:"BEST" | summary title | index title; }" -ilscript[0].content[3] "clear_state | guard { input album | tokenize normalize stem:"BEST" | index album; }" -ilscript[0].content[4] "clear_state | guard { input duration | summary duration; }" -ilscript[0].content[5] "clear_state | guard { input year | summary year | attribute year; }" -ilscript[0].content[6] "clear_state | guard { input popularity | summary popularity | attribute popularity; }" --
- Refer to linguistics for more details. -
--By default, the indexing chain is set up on the first container cluster in services.xml. -When having multiple container clusters, it is recommended to configure this explicitly, see -multiple container clusters. -
- - - --The document -can have a selection string, -normally used to expire documents. -This is also evaluated during feeding, so documents that would immediately expire are dropped. -This is not an error, the document API will report 200 - but can be confusing. -
-The evaluation is done in the - -DocumentRouteSelector at the feeding endpoint - before any processing/indexing. -I.e. the document is evaluated using the selection string (drop it or not), -then where to route it, based on document type. -
-Example: the selection is configured to not match the document being fed: -
-
-<content id="music" version="1.0">
- <redundancy>1</redundancy>
- <documents>
- <document type="music" mode="index" selection='music.album == "thisstringwillnotmatch"'/>
-
-
-
-$ vespa-feeder --trace 6 doc.json
-
-<trace>
- [1564576570.693] Source session accepted a 4096 byte message. 1 message(s) now pending.
- [1564576570.713] Sequencer sending message with sequence id '-1163801147'.
- [1564576570.721] Recognized 'default' as route 'indexing'.
- [1564576570.727] Recognized 'indexing' as HopBlueprint(selector = { '[DocumentRouteSelector]' }, recipients = { 'music' }, ignoreResult = false).
- [1564576570.811] Running routing policy 'DocumentRouteSelector'.
- [1564576570.822] Policy 'DocumentRouteSelector' assigned a reply to this branch.
- [1564576570.828] Sequencer received reply with sequence id '-1163801147'.
- [1564576570.828] Source session received reply. 0 message(s) now pending.
-</trace>
-
-Messages sent to vespa (route default) :
-----------------------------------------
-PutDocument: ok: 0 msgs/sec: 0.00 failed: 0 ignored: 1 latency(min, max, avg): 9223372036854775807, -9223372036854775808, 0
-
--Without the selection (i.e. everything matches): -
--$ vespa-feeder --trace 6 doc.json - -<trace> - [1564576637.147] Source session accepted a 4096 byte message. 1 message(s) now pending. - [1564576637.168] Sequencer sending message with sequence id '-1163801147'. - [1564576637.176] Recognized 'default' as route 'indexing'. - [1564576637.180] Recognized 'indexing' as HopBlueprint(selector = { '[DocumentRouteSelector]' }, recipients = { 'music' }, ignoreResult = false). - [1564576637.256] Running routing policy 'DocumentRouteSelector'. - [1564576637.268] Component '[MessageType:music]' selected by policy 'DocumentRouteSelector'. - ... -</trace> - -Messages sent to vespa (route default) : ----------------------------------------- -PutDocument: ok: 1 msgs/sec: 1.05 failed: 0 ignored: 0 latency(min, max, avg): 845, 845, 845 --
-In the last case, in the -DocumentRouteSelector routing policy, -the document matched the selection string / there was no selection string, -and the document was forward to the nex hop in the route. -
- - - --Add custom processing of documents using document processing. -The normal use case is to add document processors in the default route, before indexing. Example: -
--<services version="1.0"> - - <container id="container" version="1.0"> - <document-api /> - <search /> - <document-processing> - <chain id="default"> - <documentprocessor - id="com.mydomain.example.Rot13DocumentProcessor" - bundle="album-recommendation-docproc" /> - </chain> - </document-processing> - <nodes> - <node hostalias="node1" /> - </nodes> - </container> - - <content id="music" version="1.0"> - <redundancy>1</redundancy> - <documents> - <document >type="music" mode="index" /> - </documents> - <nodes> - <node hostalias="node1" distribution-key="0" /> - </nodes> - </content> - -</services> --
-Note that a new hop default/chain.default is added, -and the default route is changed to include this: -
--$ vespa-route - -There are 6 route(s): - 1. default - 2. default-get - 3. music - 4. music-direct - 5. music-index - 6. storage/cluster.music - -There are 3 hop(s): - 1. default/chain.default - 2. default/chain.indexing - 3. indexing --
-$ vespa-route --route default - -The route 'default' has 2 hop(s): - 1. default/chain.default - 2. indexing --
-Note that the document processing chain must be called default -to automatically be included in the default route. -
- - -- An alternative to the above is inheriting the indexing chain - use this when getting this error: -
--Indexing cluster 'XX' specifies the chain 'default' as indexing chain. -As the 'default' chain is run by default, using it as the indexing chain will run it twice. -Use a different name for the indexing chain. --
- Call the chain something else than default, and let it inherit indexing: -
--<services version="1.0"> - - <container id="container" version="1.0"> - <document-api /> - <search /> - <document-processing> - <chain id="offer-processing" inherits="indexing"> - <documentprocessor id="processor.OfferDocumentProcessor"/> - </chain> - </document-processing> - <nodes> - <node hostalias="node1" /> - </nodes> - </container> - - <content id="music" version="1.0"> - <redundancy>1</redundancy> - <documents> - <document type="offer" mode="index"/> - <document-processing cluster="default" chain="offer-processing"/> - </documents> - <nodes> - <node hostalias="node1" distribution-key="0" /> - </nodes> - </content> - -</services> --
See #13193 for details.
@@ -378,185 +65,3 @@date
field above is placed
outside the document
section,
as its content is generated from the document input.' %}
-
-
-
--Vespa can be configured to use more than one container cluster. -Use cases can be to separate search and document processing -or having different document processing clusters due to capacity constraints or dependencies. -Example with separate search and feeding/indexing container clusters: -
--<services version="1.0"> - - <container id="container-search" version="1.0"> - <search /> - <nodes> - <node hostalias="node1" /> - </nodes> - </container> - - <container id="container-indexing" version="1.0"> - <http> - <server id="httpServer2" port="8081" /> - </http> - <document-api /> - <document-processing /> - <nodes> - <node hostalias="node1" /> - </nodes> - </container> - - <content id="music" version="1.0"> - <redundancy>1</redundancy> - <documents> - <document type="music" mode="index" /> - <document-processing cluster="container-indexing" /> - </documents> - <nodes> - <node hostalias="node1" distribution-key="0" /> - </nodes> - </content> - -</services> --
Notes:
--Observe the container-indexing/chain.indexing hop, -and the indexing chain is set up on the container-indexing cluster: -
--$ vespa-route - -There are 6 route(s): - 1. default - 2. default-get - 3. music - 4. music-direct - 5. music-index - 6. storage/cluster.music - -There are 2 hop(s): - 1. container-indexing/chain.indexing - 2. indexing --
-$ curl -s http://localhost:8081 | python -m json.tool | grep -C 3 chain.indexing - - { - "bundle": "container-disc:7.0.0", - "class": "com.yahoo.messagebus.jdisc.MbusClient", - "id": "chain.indexing@MbusClient", - "serverBindings": [] - }, - { --- - "class": "com.yahoo.docproc.jdisc.DocumentProcessingHandler", - "id": "com.yahoo.docproc.jdisc.DocumentProcessingHandler", - "serverBindings": [ - "mbus://*/chain.indexing" - ] - }, - { - -- - - -
-Below is a trace example, no selection string: -
--$ cat doc.json -[ -{ - "put": "id:mynamespace:music::123", - "fields": { - "album": "Bad", - "artist": "Michael Jackson", - "title": "Bad", - "year": 1987, - "duration": 247 - } -} -] - -$ vespa-feeder --trace 6 doc.json -<trace> - [1564571762.403] Source session accepted a 4096 byte message. 1 message(s) now pending. - [1564571762.420] Sequencer sending message with sequence id '-1163801147'. - [1564571762.426] Recognized 'default' as route 'indexing'. - [1564571762.429] Recognized 'indexing' as HopBlueprint(selector = { '[DocumentRouteSelector]' }, recipients = { 'music' }, ignoreResult = false). - [1564571762.489] Running routing policy 'DocumentRouteSelector'. - [1564571762.493] Component '[MessageType:music]' selected by policy 'DocumentRouteSelector'. - [1564571762.493] Resolving '[MessageType:music]'. - [1564571762.520] Running routing policy 'MessageType'. - [1564571762.520] Component 'music-index' selected by policy 'MessageType'. - [1564571762.520] Resolving 'music-index'. - [1564571762.520] Recognized 'music-index' as route 'container/chain.indexing [Content:cluster=music]'. - [1564571762.520] Recognized 'container/chain.indexing' as HopBlueprint(selector = { '[LoadBalancer:cluster=container;session=chain.indexing]' }, recipients = { }, ignoreResult = false). - [1564571762.526] Running routing policy 'LoadBalancer'. - [1564571762.538] Component 'tcp/vespa-container:19101/chain.indexing' selected by policy 'LoadBalancer'. - [1564571762.538] Resolving 'tcp/vespa-container:19101/chain.indexing [Content:cluster=music]'. - [1564571762.580] Sending message (version 7.83.27) from client to 'tcp/vespa-container:19101/chain.indexing' with 179.853 seconds timeout. - [1564571762.581] Message (type 100004) received at 'container/container.0' for session 'chain.indexing'. - [1564571762.581] Message received by MbusServer. - [1564571762.582] Request received by MbusClient. - [1564571762.582] Running routing policy 'Content'. - [1564571762.582] Selecting route - [1564571762.582] No cluster state cached. Sending to random distributor. - [1564571762.582] Too few nodes seen up in state. Sending totally random. - [1564571762.582] Component 'tcp/vespa-container:19114/default' selected by policy 'Content'. - [1564571762.582] Resolving 'tcp/vespa-container:19114/default'. - [1564571762.586] Sending message (version 7.83.27) from 'container/container.0' to 'tcp/vespa-container:19114/default' with 179.995 seconds timeout. - [1564571762.587181] Message (type 100004) received at 'storage/cluster.music/distributor/0' for session 'default'. - [1564571762.587245] music/distributor/0 CommunicationManager: Received message from message bus - [1564571762.587510] Communication manager: Sending Put(BucketId(0x2000000000000020), id:mynamespace:music::123, timestamp 1564571762000000, size 275) - [1564571762.587529] Communication manager: Passing message to source session - [1564571762.587547] Source session accepted a 1 byte message. 1 message(s) now pending. - [1564571762.587681] Sending message (version 7.83.27) from 'storage/cluster.music/distributor/0' to 'storage/cluster.music/storage/0/default' with 180.00 seconds timeout. - [1564571762.587960] Message (type 10) received at 'storage/cluster.music/storage/0' for session 'default'. - [1564571762.588052] music/storage/0 CommunicationManager: Received message from message bus - [1564571762.588263] PersistenceThread: Processing message in persistence layer - [1564571762.588953] Communication manager: Sending PutReply(id:mynamespace:music::123, BucketId(0x2000000000000020), timestamp 1564571762000000) - [1564571762.589023] Sending reply (version 7.83.27) from 'storage/cluster.music/storage/0'. - [1564571762.589332] Reply (type 11) received at 'storage/cluster.music/distributor/0'. - [1564571762.589448] Source session received reply. 0 message(s) now pending. - [1564571762.589459] music/distributor/0Communication manager: Received reply from message bus - [1564571762.589679] Communication manager: Sending PutReply(id:music:music::123, BucketId(0x0000000000000000), timestamp 1564571762000000) - [1564571762.589807] Sending reply (version 7.83.27) from 'storage/cluster.music/distributor/0'. - [1564571762.590] Reply (type 200004) received at 'container/container.0'. - [1564571762.590] Routing policy 'Content' merging replies. - [1564571762.590] Reply received by MbusClient. - [1564571762.590] Sending reply from MbusServer. - [1564571762.590] Sending reply (version 7.83.27) from 'container/container.0'. - [1564571762.612] Reply (type 200004) received at client. - [1564571762.613] Routing policy 'LoadBalancer' merging replies. - [1564571762.613] Routing policy 'MessageType' merging replies. - [1564571762.615] Routing policy 'DocumentRouteSelector' merging replies. - [1564571762.622] Sequencer received reply with sequence id '-1163801147'. - [1564571762.622] Source session received reply. 0 message(s) now pending. -</trace> - -Messages sent to vespa (route default) : ----------------------------------------- -PutDocument: ok: 1 msgs/sec: 3.30 failed: 0 ignored: 0 latency(min, max, avg): 225, 225, 225 -diff --git a/en/operations-selfhosted/routing.html b/en/operations-selfhosted/routing.html index f3f8286643..36439d68c2 100644 --- a/en/operations-selfhosted/routing.html +++ b/en/operations-selfhosted/routing.html @@ -5,6 +5,7 @@ - /documentation/routing.html - /en/routing.html - /en/reference/services-routing.html +- /en/reference/routingpolicies.html ---
@@ -13,16 +14,16 @@ configuration which is appropriate for most cases, so no explicit routing configuration is necessary. However, explicit routing can be used in advanced use cases such as sending different document streams to different document processing -clusters, or through multiple consecutive clusters etc.
- -There are other, more in-depth, articles on routing: +clusters, or through multiple consecutive clusters etc. +
+There are other, more in-depth, articles on routing:
-Refer to the routing policy reference. +Refer to the routing policy reference.
@@ -224,7 +225,7 @@This hop has a selector but no recipients. The reason for this is best explained in -the policies article, +the routing policies reference, but it serves as an example of a hop that has no configured recipients. Notice how the policy directive contains a colon (":") which denotes that the remainder of the directive is a parameter to the policy constructor. @@ -233,8 +234,8 @@
What routing policies are available depends on what protocol is currently running. As of this version the only supported protocol is "Document". -This offers a set of routing policies discussed in -this article. +This offers a set of routing policies discussed +below.
@@ -660,3 +661,771 @@+ This article contains detailed descriptions of the behaviour of all routing policies available in Vespa. +
+ The Document protocol is currently the only Message Bus protocol supported by Vespa. + Furthermore, all routing policies that are part of this protocol + share a common code path for merging replies. + The policies offered by the protocol are: +
+merge()
logic+ The shared merge logic of most Document routing policies is an attempt to + do the "right" thing when merging multiple replies into one. + It works by first stepping through all replies, storing their content as either: +
++ If at least one ERROR reply is found, return a new reply that contains all the errors of the others. + If there is at least one OK reply, return the first OK reply, + but transfer all feed information from the others to this + (this is specific data for start- and end-of-feed messages). + Otherwise, return a new reply that contains all the IGNORE errors. Pseudocode: +
++for each reply, do + if reply has no errors, do + store reply in OK list + else, do + if reply has only IGNORE errors + copy all errors from reply to IGNORE list + else, do + copy all errors from reply to ERROR list + +if ERROR list is not empty, do + return new reply with all errors +else, do + if OK list is not empty, do + return first reply with all feed answers + else, do + return new reply with all IGNORE errors ++ + + +
Policy | +Description | +||||||
---|---|---|---|---|---|---|---|
AND | ++ This is a mostly a convenience policy + that allows the user to fork a message's route to all configured recipients. + It is not message-type aware, and will simply always select all recipients. + Replies are merged according to the shared logic. + + The optional string parameter is parsed as a space-separated list of hops. + Configured recipients have precedence over parameter-given recipients, + although this is likely to be changed in the future. + |
+ ||||||
DocumentRouteSelector | ++ This policy is responsible for selecting among the policy's recipients + according to the subscription rules defined by a content cluster's documents element + in services.xml. + If the "selection" attribute is set in the "documents" element, + its value is processed as a document select string, + and run on documents and document updates to determine routes. + If the "feedname" attribute is set, all feed commands are filtered through it. + + The recipient list of this policy is required to map directly to route names. + E.g. if a recipient is "search/cluster.music", and a message is appropriate according to the selection criteria, + the message is routed to the "search/cluster.music" route. + If the route does not exist, this policy will reply with an error. + In short, this policy selects one or more recipient routes based on document content and configured criteria. + + If more than one route is chosen, its replies are merged according to the shared logic. + + This policy does not support any parameters. + + The configuration for this is "documentrouteselectorpolicy" available from config id "routing/documentapi". + + {% include important.html content="Because GET messages do not contain any document on which to run the selection criteria, + this policy returns an IGNORED reply that the merging logic processes. + You can see this by attempting to retrieve a document from an application that does not have a content cluster."%} + |
+ ||||||
Content + | + This policy allows you to send a message to a content cluster. + The policy uses a system state retrieved from the cluster in question + in conjunction with slobrok information to pick the correct distributor for your message. + + In short; use this policy when communicating with document storage. + + This policy supports multiple parameters, up to one each of: + +
|
+ ||||||
MessageType | ++ This policy will select the next hop based on the type of the message. + You configure where all messages should go (defaultroute). + Then you configure what messages types should be overridden and sent to alternative routes. + It is currently only used internally by vespa when using the + content element. + |
+ ||||||
Extern | ++ This policy implements the necessary logic to communicate with an external Vespa application + and resolve a single service pattern using that other application's slobrok servers. + Keep in mind that there might be some delay from the moment this policy is initially created + and when it receives the response to its service query, + so using this policy might cause a message to be resent a few times until it is resolved. + If you disable retries, this policy might cause all messages to fail for the first seconds. +
+ This policy uses its parameter for both the address of the extern slobrok server to connect to,
+ and also the pattern to use for querying.
+ The parameter is required to be on the form |
+ ||||||
LocalService | ++ This policy is used to select among all matching services, + but preferring those running on the same host as the current one. + The pattern used when querying for available services is the current one, + but replacing the policy directive with an asterisk. + E.g. the hop "docproc/cluster.default/[LocalService]/chain.default" would prefer local services + among all those that match the pattern "docproc/cluster.default/*/chain.default". + If there are multiple matching services that run locally, + this policy will do simple round-robin load balancing between them. + If no matching services run locally, + this policy simply returns the asterisk as a match to allow the underlying network logic + to do load balancing among all available. + + This policy accepts an optional parameter which overrides the local hostname. + Use this if you wish the hop to prefer some specific host. + + {% include important.html content="There is no additional logic to replace other policy directives with an asterisk, + meaning that if other policies directives are present in the hop string + after \"[LocalService]\", + no services can possibly be matched."%} + |
+ ||||||
RoundRobin | ++ This policy is used to select among a configured set of recipients. + For each configured recipient, this policy determines what online services are matched, + and then selects one among all of those in round-robin order. + If none of the configured recipients match any available service, + this policy returns an error that indicates to the sender that it should retry later. + + Because this policy only selects a single recipient, it contains no merging logic. + |
+ ||||||
SubsetService | ++ This policy is used to select among a subset of all matching services, + and is used to minimize number of connections in the system. + The pattern used when querying for available services is the current one, + but replacing the policy directive with an asterisk. + E.g. the hop "docproc/cluster.default/[SubsetService:3]/chain.default" + would select among a subset of all those that match the pattern "docproc/cluster.default/*/chain.default". + Given that the pattern returns a set of matches, + this policy stores a subset of these based on the hash-value of the running message bus' + connection string (this is unique for each instance). + If there are no matching services, + this policy returns the asterisk as a match to allow the underlying network logic to fail gracefully. + + This policy parses its optional parameter as the size of the subset. + If none is given, the subset defaults to size 5. + + {% include important.html content="There is no additional logic to replace other policy directives with an asterisk, + meaning that if other policies directives are present in the hop string + after \"[SubsetService]\", + no services can possibly be matched."%} + |
+ ||||||
LoadBalancer | ++ This policy is used to send to a stateless cluster such as docproc, + where any node can be chosen to process any message. + Messages are sent between the nodes in a round-robin fashion, + but each node is assigned a weight based on its performance. + The weights are calculated by measuring the number of times the node had a full input-queue + and returned a busy response. + Use this policy to send to docproc clusters that have nodes with different performance characteristics. + + This policy supports multiple parameters, up to one each of: + +
|
+
+ A normal Vespa configuration has container and content cluster(s), + with one or more document types defined in schemas. + Routing document writes means routing documents to the indexing container cluster, + then the right content cluster. +
++ The indexing cluster is a container cluster - + see multiple container clusters for variants. + Add the document-api + feed endpoint to this cluster. + The mapping from document type to content cluster is in + document in the content cluster. + From + album-recommendation: +
++<services version="1.0"> + + <container id="container" version="1.0"> + <document-api /> + <search /> + <nodes> + <node hostalias="node1" /> + </nodes> + </container> + + <content id="music" version="1.0"> + <redundancy>1</redundancy> + <documents> + <document type="music" mode="index" /> + </documents> + <nodes> + <node hostalias="node1" distribution-key="0" /> + </nodes> + </content> + +</services> ++
+ Given this configuration, Vespa knows which is the container cluster used for indexing, + and which content cluster that stores the music document type. + Use vespa-route + to display routing generated from this configuration: +
++$ vespa-route +There are 6 route(s): + 1. default + 2. default-get + 3. music + 4. music-direct + 5. music-index + 6. storage/cluster.music + +There are 2 hop(s): + 1. container/chain.indexing + 2. indexing ++
+ Note the default route. This route is auto-generated by Vespa, + and is used when no other route is used when using /document/v1. + default points to indexing: +
++$ vespa-route --route default +The route 'default' has 1 hop(s): + 1. indexing ++
+$ vespa-route --hop indexing +The hop 'indexing' has selector: + [DocumentRouteSelector] +And 1 recipient(s): + 1. music ++
+$ vespa-route --route music +The route 'music' has 1 hop(s): + 1. [MessageType:music] ++
+ In short, the default route handles documents of type music. + Vespa will route to the container cluster with document-api - + note the chain.indexing above. + This is a set of built-in document processors that does the indexing (below). +
+ Refer to the trace appendix for routing details. +
+ + + +
+ This indexing chain is set up on the container once a content cluster has mode="index"
.
+
+ The + IndexingProcessor + annotates the document based on the indexing script + generated from the schema. Example: +
++$ vespa-get-config -n vespa.configdefinition.ilscripts \ + -i container/docprocchains/chain/indexing/component/com.yahoo.docprocs.indexing.IndexingProcessor + +maxtermoccurrences 100 +fieldmatchmaxlength 1000000 +ilscript[0].doctype "music" +ilscript[0].docfield[0] "artist" +ilscript[0].docfield[1] "artistId" +ilscript[0].docfield[2] "title" +ilscript[0].docfield[3] "album" +ilscript[0].docfield[4] "duration" +ilscript[0].docfield[5] "year" +ilscript[0].docfield[6] "popularity" +ilscript[0].content[0] "clear_state | guard { input artist | tokenize normalize stem:"BEST" | summary artist | index artist; }" +ilscript[0].content[1] "clear_state | guard { input artistId | summary artistId | attribute artistId; }" +ilscript[0].content[2] "clear_state | guard { input title | tokenize normalize stem:"BEST" | summary title | index title; }" +ilscript[0].content[3] "clear_state | guard { input album | tokenize normalize stem:"BEST" | index album; }" +ilscript[0].content[4] "clear_state | guard { input duration | summary duration; }" +ilscript[0].content[5] "clear_state | guard { input year | summary year | attribute year; }" +ilscript[0].content[6] "clear_state | guard { input popularity | summary popularity | attribute popularity; }" ++
+ Refer to linguistics for more details. +
++ By default, the indexing chain is set up on the first container cluster in services.xml. + When having multiple container clusters, it is recommended to configure this explicitly, see + multiple container clusters. +
+ + + ++ The document + can have a selection string, + normally used to expire documents. + This is also evaluated during feeding, so documents that would immediately expire are dropped. + This is not an error, the document API will report 200 - but can be confusing. +
+ The evaluation is done in the + + DocumentRouteSelector at the feeding endpoint - before any processing/indexing. + I.e. the document is evaluated using the selection string (drop it or not), + then where to route it, based on document type. +
+ Example: the selection is configured to not match the document being fed: +
+
+<content id="music" version="1.0">
+ <redundancy>1</redundancy>
+ <documents>
+ <document type="music" mode="index" selection='music.album == "thisstringwillnotmatch"'/>
+
+
+
+$ vespa-feeder --trace 6 doc.json
+
+<trace>
+ [1564576570.693] Source session accepted a 4096 byte message. 1 message(s) now pending.
+ [1564576570.713] Sequencer sending message with sequence id '-1163801147'.
+ [1564576570.721] Recognized 'default' as route 'indexing'.
+ [1564576570.727] Recognized 'indexing' as HopBlueprint(selector = { '[DocumentRouteSelector]' }, recipients = { 'music' }, ignoreResult = false).
+ [1564576570.811] Running routing policy 'DocumentRouteSelector'.
+ [1564576570.822] Policy 'DocumentRouteSelector' assigned a reply to this branch.
+ [1564576570.828] Sequencer received reply with sequence id '-1163801147'.
+ [1564576570.828] Source session received reply. 0 message(s) now pending.
+</trace>
+
+Messages sent to vespa (route default) :
+----------------------------------------
+PutDocument: ok: 0 msgs/sec: 0.00 failed: 0 ignored: 1 latency(min, max, avg): 9223372036854775807, -9223372036854775808, 0
+
++ Without the selection (i.e. everything matches): +
++$ vespa-feeder --trace 6 doc.json + +<trace> + [1564576637.147] Source session accepted a 4096 byte message. 1 message(s) now pending. + [1564576637.168] Sequencer sending message with sequence id '-1163801147'. + [1564576637.176] Recognized 'default' as route 'indexing'. + [1564576637.180] Recognized 'indexing' as HopBlueprint(selector = { '[DocumentRouteSelector]' }, recipients = { 'music' }, ignoreResult = false). + [1564576637.256] Running routing policy 'DocumentRouteSelector'. + [1564576637.268] Component '[MessageType:music]' selected by policy 'DocumentRouteSelector'. + ... +</trace> + +Messages sent to vespa (route default) : +---------------------------------------- +PutDocument: ok: 1 msgs/sec: 1.05 failed: 0 ignored: 0 latency(min, max, avg): 845, 845, 845 ++
+ In the last case, in the + DocumentRouteSelector routing policy, + the document matched the selection string / there was no selection string, + and the document was forward to the nex hop in the route. +
+ + + ++ Add custom processing of documents using document processing. + The normal use case is to add document processors in the default route, before indexing. Example: +
++<services version="1.0"> + + <container id="container" version="1.0"> + <document-api /> + <search /> + <document-processing> + <chain id="default"> + <documentprocessor + id="com.mydomain.example.Rot13DocumentProcessor" + bundle="album-recommendation-docproc" /> + </chain> + </document-processing> + <nodes> + <node hostalias="node1" /> + </nodes> + </container> + + <content id="music" version="1.0"> + <redundancy>1</redundancy> + <documents> + <document >type="music" mode="index" /> + </documents> + <nodes> + <node hostalias="node1" distribution-key="0" /> + </nodes> + </content> + +</services> ++
+ Note that a new hop default/chain.default is added, + and the default route is changed to include this: +
++$ vespa-route + +There are 6 route(s): + 1. default + 2. default-get + 3. music + 4. music-direct + 5. music-index + 6. storage/cluster.music + +There are 3 hop(s): + 1. default/chain.default + 2. default/chain.indexing + 3. indexing ++
+$ vespa-route --route default + +The route 'default' has 2 hop(s): + 1. default/chain.default + 2. indexing ++
+ Note that the document processing chain must be called default + to automatically be included in the default route. +
+ + ++ An alternative to the above is inheriting the indexing chain - use this when getting this error: +
++Indexing cluster 'XX' specifies the chain 'default' as indexing chain. +As the 'default' chain is run by default, using it as the indexing chain will run it twice. +Use a different name for the indexing chain. ++
+ Call the chain something else than default, and let it inherit indexing: +
++<services version="1.0"> + + <container id="container" version="1.0"> + <document-api /> + <search /> + <document-processing> + <chain id="offer-processing" inherits="indexing"> + <documentprocessor id="processor.OfferDocumentProcessor"/> + </chain> + </document-processing> + <nodes> + <node hostalias="node1" /> + </nodes> + </container> + + <content id="music" version="1.0"> + <redundancy>1</redundancy> + <documents> + <document type="offer" mode="index"/> + <document-processing cluster="default" chain="offer-processing"/> + </documents> + <nodes> + <node hostalias="node1" distribution-key="0" /> + </nodes> + </content> + +</services> ++
See #13193 for details.
+ + + ++ Vespa can be configured to use more than one container cluster. + Use cases can be to separate search and document processing + or having different document processing clusters due to capacity constraints or dependencies. + Example with separate search and feeding/indexing container clusters: +
++<services version="1.0"> + + <container id="container-search" version="1.0"> + <search /> + <nodes> + <node hostalias="node1" /> + </nodes> + </container> + + <container id="container-indexing" version="1.0"> + <http> + <server id="httpServer2" port="8081" /> + </http> + <document-api /> + <document-processing /> + <nodes> + <node hostalias="node1" /> + </nodes> + </container> + + <content id="music" version="1.0"> + <redundancy>1</redundancy> + <documents> + <document type="music" mode="index" /> + <document-processing cluster="container-indexing" /> + </documents> + <nodes> + <node hostalias="node1" distribution-key="0" /> + </nodes> + </content> + +</services> ++
Notes:
++ Observe the container-indexing/chain.indexing hop, + and the indexing chain is set up on the container-indexing cluster: +
++$ vespa-route + +There are 6 route(s): + 1. default + 2. default-get + 3. music + 4. music-direct + 5. music-index + 6. storage/cluster.music + +There are 2 hop(s): + 1. container-indexing/chain.indexing + 2. indexing ++
+$ curl -s http://localhost:8081 | python -m json.tool | grep -C 3 chain.indexing + + { + "bundle": "container-disc:7.0.0", + "class": "com.yahoo.messagebus.jdisc.MbusClient", + "id": "chain.indexing@MbusClient", + "serverBindings": [] + }, + { +-- + "class": "com.yahoo.docproc.jdisc.DocumentProcessingHandler", + "id": "com.yahoo.docproc.jdisc.DocumentProcessingHandler", + "serverBindings": [ + "mbus://*/chain.indexing" + ] + }, + { + ++ + + +
+ Below is a trace example, no selection string: +
++$ cat doc.json +[ +{ + "put": "id:mynamespace:music::123", + "fields": { + "album": "Bad", + "artist": "Michael Jackson", + "title": "Bad", + "year": 1987, + "duration": 247 + } +} +] + +$ vespa-feeder --trace 6 doc.json +<trace> + [1564571762.403] Source session accepted a 4096 byte message. 1 message(s) now pending. + [1564571762.420] Sequencer sending message with sequence id '-1163801147'. + [1564571762.426] Recognized 'default' as route 'indexing'. + [1564571762.429] Recognized 'indexing' as HopBlueprint(selector = { '[DocumentRouteSelector]' }, recipients = { 'music' }, ignoreResult = false). + [1564571762.489] Running routing policy 'DocumentRouteSelector'. + [1564571762.493] Component '[MessageType:music]' selected by policy 'DocumentRouteSelector'. + [1564571762.493] Resolving '[MessageType:music]'. + [1564571762.520] Running routing policy 'MessageType'. + [1564571762.520] Component 'music-index' selected by policy 'MessageType'. + [1564571762.520] Resolving 'music-index'. + [1564571762.520] Recognized 'music-index' as route 'container/chain.indexing [Content:cluster=music]'. + [1564571762.520] Recognized 'container/chain.indexing' as HopBlueprint(selector = { '[LoadBalancer:cluster=container;session=chain.indexing]' }, recipients = { }, ignoreResult = false). + [1564571762.526] Running routing policy 'LoadBalancer'. + [1564571762.538] Component 'tcp/vespa-container:19101/chain.indexing' selected by policy 'LoadBalancer'. + [1564571762.538] Resolving 'tcp/vespa-container:19101/chain.indexing [Content:cluster=music]'. + [1564571762.580] Sending message (version 7.83.27) from client to 'tcp/vespa-container:19101/chain.indexing' with 179.853 seconds timeout. + [1564571762.581] Message (type 100004) received at 'container/container.0' for session 'chain.indexing'. + [1564571762.581] Message received by MbusServer. + [1564571762.582] Request received by MbusClient. + [1564571762.582] Running routing policy 'Content'. + [1564571762.582] Selecting route + [1564571762.582] No cluster state cached. Sending to random distributor. + [1564571762.582] Too few nodes seen up in state. Sending totally random. + [1564571762.582] Component 'tcp/vespa-container:19114/default' selected by policy 'Content'. + [1564571762.582] Resolving 'tcp/vespa-container:19114/default'. + [1564571762.586] Sending message (version 7.83.27) from 'container/container.0' to 'tcp/vespa-container:19114/default' with 179.995 seconds timeout. + [1564571762.587181] Message (type 100004) received at 'storage/cluster.music/distributor/0' for session 'default'. + [1564571762.587245] music/distributor/0 CommunicationManager: Received message from message bus + [1564571762.587510] Communication manager: Sending Put(BucketId(0x2000000000000020), id:mynamespace:music::123, timestamp 1564571762000000, size 275) + [1564571762.587529] Communication manager: Passing message to source session + [1564571762.587547] Source session accepted a 1 byte message. 1 message(s) now pending. + [1564571762.587681] Sending message (version 7.83.27) from 'storage/cluster.music/distributor/0' to 'storage/cluster.music/storage/0/default' with 180.00 seconds timeout. + [1564571762.587960] Message (type 10) received at 'storage/cluster.music/storage/0' for session 'default'. + [1564571762.588052] music/storage/0 CommunicationManager: Received message from message bus + [1564571762.588263] PersistenceThread: Processing message in persistence layer + [1564571762.588953] Communication manager: Sending PutReply(id:mynamespace:music::123, BucketId(0x2000000000000020), timestamp 1564571762000000) + [1564571762.589023] Sending reply (version 7.83.27) from 'storage/cluster.music/storage/0'. + [1564571762.589332] Reply (type 11) received at 'storage/cluster.music/distributor/0'. + [1564571762.589448] Source session received reply. 0 message(s) now pending. + [1564571762.589459] music/distributor/0Communication manager: Received reply from message bus + [1564571762.589679] Communication manager: Sending PutReply(id:music:music::123, BucketId(0x0000000000000000), timestamp 1564571762000000) + [1564571762.589807] Sending reply (version 7.83.27) from 'storage/cluster.music/distributor/0'. + [1564571762.590] Reply (type 200004) received at 'container/container.0'. + [1564571762.590] Routing policy 'Content' merging replies. + [1564571762.590] Reply received by MbusClient. + [1564571762.590] Sending reply from MbusServer. + [1564571762.590] Sending reply (version 7.83.27) from 'container/container.0'. + [1564571762.612] Reply (type 200004) received at client. + [1564571762.613] Routing policy 'LoadBalancer' merging replies. + [1564571762.613] Routing policy 'MessageType' merging replies. + [1564571762.615] Routing policy 'DocumentRouteSelector' merging replies. + [1564571762.622] Sequencer received reply with sequence id '-1163801147'. + [1564571762.622] Source session received reply. 0 message(s) now pending. +</trace> + +Messages sent to vespa (route default) : +---------------------------------------- +PutDocument: ok: 1 msgs/sec: 3.30 failed: 0 ignored: 0 latency(min, max, avg): 225, 225, 225 +diff --git a/en/operations/reindexing.html b/en/operations/reindexing.html index fba930e9d5..9807a62943 100644 --- a/en/operations/reindexing.html +++ b/en/operations/reindexing.html @@ -43,7 +43,7 @@
Reindexing is done by a component in each content cluster that visits all documents of the indicated types, - and re-feeds these through the indexing chain of the cluster. + and re-feeds these through the indexing chain of the cluster. (Note that only the document fields are re-fed — all derived fields, produced by the indexing pipeline, are recomputed.) The reindexing process avoids write races with concurrent feed by locking diff --git a/en/operations/using-kubernetes-with-vespa.html b/en/operations/using-kubernetes-with-vespa.html index 63a549ed51..7eae7cf286 100644 --- a/en/operations/using-kubernetes-with-vespa.html +++ b/en/operations/using-kubernetes-with-vespa.html @@ -17,7 +17,7 @@ Use the multinode-HA sample application as a basis for configuration.
-- Indexing + Indexing and/or document processing is a chain of processors that manipulate documents before they are stored. Document processors can be user defined. diff --git a/en/reference/routingpolicies.html b/en/reference/routingpolicies.html deleted file mode 100644 index 82fd721da4..0000000000 --- a/en/reference/routingpolicies.html +++ /dev/null @@ -1,272 +0,0 @@ ---- -# Copyright Yahoo. Licensed under the terms of the Apache 2.0 license. See LICENSE in the project root. -title: "Routingpolicies Reference" -redirect_from: -- /documentation/reference/routingpolicies.html ---- - -
- This article contains detailed descriptions of the behaviour of all routing policies available in Vespa. - There is also a more general article on Vespa's routing model available. -
- The Document protocol is currently the only Message Bus protocol supported by Vespa. - Furthermore, all routing policies that are part of this protocol - share a common code path for merging replies. - The policies offered by the protocol are: -
-merge()
logic- The shared merge logic of most Document routing policies is an attempt to - do the "right" thing when merging multiple replies into one. - It works by first stepping through all replies, storing their content as either: -
--If at least one ERROR reply is found, return a new reply that contains all the errors of the others. -If there is at least one OK reply, return the first OK reply, -but transfer all feed information from the others to this -(this is specific data for start- and end-of-feed messages). -Otherwise, return a new reply that contains all the IGNORE errors. Pseudocode: -
--for each reply, do - if reply has no errors, do - store reply in OK list - else, do - if reply has only IGNORE errors - copy all errors from reply to IGNORE list - else, do - copy all errors from reply to ERROR list - -if ERROR list is not empty, do - return new reply with all errors -else, do - if OK list is not empty, do - return first reply with all feed answers - else, do - return new reply with all IGNORE errors -- - - -
Policy | -Description | -||||||
---|---|---|---|---|---|---|---|
AND | -- This is a mostly a convenience policy - that allows the user to fork a message's route to all configured recipients. - It is not message-type aware, and will simply always select all recipients. - Replies are merged according to the shared logic. - - The optional string parameter is parsed as a space-separated list of hops. - Configured recipients have precedence over parameter-given recipients, - although this is likely to be changed in the future. - |
- ||||||
DocumentRouteSelector | -- This policy is responsible for selecting among the policy's recipients - according to the subscription rules defined by a content cluster's documents element - in services.xml. - If the "selection" attribute is set in the "documents" element, - its value is processed as a document select string, - and run on documents and document updates to determine routes. - If the "feedname" attribute is set, all feed commands are filtered through it. - - The recipient list of this policy is required to map directly to route names. - E.g. if a recipient is "search/cluster.music", and a message is appropriate according to the selection criteria, - the message is routed to the "search/cluster.music" route. - If the route does not exist, this policy will reply with an error. - In short, this policy selects one or more recipient routes based on document content and configured criteria. - - If more than one route is chosen, its replies are merged according to the shared logic. - - This policy does not support any parameters. - - The configuration for this is "documentrouteselectorpolicy" available from config id "routing/documentapi". - - {% include important.html content="Because GET messages do not contain any document on which to run the selection criteria, - this policy returns an IGNORED reply that the merging logic processes. - You can see this by attempting to retrieve a document from an application that does not have a content cluster."%} - |
- ||||||
Content - | - This policy allows you to send a message to a content cluster. - The policy uses a system state retrieved from the cluster in question - in conjunction with slobrok information to pick the correct distributor for your message. - - In short; use this policy when communicating with document storage. - - This policy supports multiple parameters, up to one each of: - -
|
- ||||||
MessageType | -- This policy will select the next hop based on the type of the message. - You configure where all messages should go (defaultroute). - Then you configure what messages types should be overridden and sent to alternative routes. - It is currently only used internally by vespa when using the - content element. - |
- ||||||
Extern | -- This policy implements the necessary logic to communicate with an external Vespa application - and resolve a single service pattern using that other application's slobrok servers. - Keep in mind that there might be some delay from the moment this policy is initially created - and when it receives the response to its service query, - so using this policy might cause a message to be resent a few times until it is resolved. - If you disable retries, this policy might cause all messages to fail for the first seconds. -
- This policy uses its parameter for both the address of the extern slobrok server to connect to,
- and also the pattern to use for querying.
- The parameter is required to be on the form |
- ||||||
LocalService | -- This policy is used to select among all matching services, - but preferring those running on the same host as the current one. - The pattern used when querying for available services is the current one, - but replacing the policy directive with an asterisk. - E.g. the hop "docproc/cluster.default/[LocalService]/chain.default" would prefer local services - among all those that match the pattern "docproc/cluster.default/*/chain.default". - If there are multiple matching services that run locally, - this policy will do simple round-robin load balancing between them. - If no matching services run locally, - this policy simply returns the asterisk as a match to allow the underlying network logic - to do load balancing among all available. - - This policy accepts an optional parameter which overrides the local hostname. - Use this if you wish the hop to prefer some specific host. - - {% include important.html content="There is no additional logic to replace other policy directives with an asterisk, - meaning that if other policies directives are present in the hop string - after \"[LocalService]\", - no services can possibly be matched."%} - |
- ||||||
RoundRobin | -- This policy is used to select among a configured set of recipients. - For each configured recipient, this policy determines what online services are matched, - and then selects one among all of those in round-robin order. - If none of the configured recipients match any available service, - this policy returns an error that indicates to the sender that it should retry later. - - Because this policy only selects a single recipient, it contains no merging logic. - |
- ||||||
SubsetService | -- This policy is used to select among a subset of all matching services, - and is used to minimize number of connections in the system. - The pattern used when querying for available services is the current one, - but replacing the policy directive with an asterisk. - E.g. the hop "docproc/cluster.default/[SubsetService:3]/chain.default" - would select among a subset of all those that match the pattern "docproc/cluster.default/*/chain.default". - Given that the pattern returns a set of matches, - this policy stores a subset of these based on the hash-value of the running message bus' - connection string (this is unique for each instance). - If there are no matching services, - this policy returns the asterisk as a match to allow the underlying network logic to fail gracefully. - - This policy parses its optional parameter as the size of the subset. - If none is given, the subset defaults to size 5. - - {% include important.html content="There is no additional logic to replace other policy directives with an asterisk, - meaning that if other policies directives are present in the hop string - after \"[SubsetService]\", - no services can possibly be matched."%} - |
- ||||||
LoadBalancer | -- This policy is used to send to a stateless cluster such as docproc, - where any node can be chosen to process any message. - Messages are sent between the nodes in a round-robin fashion, - but each node is assigned a weight based on its performance. - The weights are calculated by measuring the number of times the node had a full input-queue - and returned a busy response. - Use this policy to send to docproc clusters that have nodes with different performance characteristics. - - This policy supports multiple parameters, up to one each of: - -
|
-
- This is the reference documentation for all elements in - the routing section of services.xml. -
--routing [version] - routingtable [protocol, verify] - route [name, hops] - hop [name, selector, ignore-result] - recipient [session] - services [protocol] - service [name] -- - - -
- Contained in services. - The container element for all configuration related to routing. -
-Attribute | Required | Value | Default | Description |
---|---|---|---|---|
version | -required | -number | -- | Must be set to "1.0" in this Vespa-version |
Optional subelements:
-Example:
--<routing version="1.0"> - <routingtable protocol="document"> - <route name="route1" hops="hop1 hop2" /> - <route name="route2" hops="hop3 hop4 hop5" /> - <hop name="hop1" selector="docproc/cluster.foo/docproc/*/feed-processor"> - <recipient session="docproc/cluster.foo/docproc/*/feed-processor" /> - </hop> - <hop name="hop2" selector="search/cluster.bar/[SearchGroup]/[SearchRow]/[SearchColumn]/feed-destination"> - <recipient session="search/cluster.bar/g0/c0/r0/feed-destination" /> - <recipient session="search/cluster.bar/g0/c1/r0/feed-destination" /> - <recipient session="search/cluster.bar/g0/c0/r1/feed-destination" /> - <recipient session="search/cluster.bar/g0/c1/r1/feed-destination" /> - <recipient session="search/cluster.bar/g1/c0/r0/feed-destination" /> - <recipient session="search/cluster.bar/g1/c1/r0/feed-destination" /> - <recipient session="search/cluster.bar/g1/c0/r1/feed-destination" /> - <recipient session="search/cluster.bar/g1/c1/r1/feed-destination" /> - </hop> - </routingtable> - <services protocol="document"> - <service name="foo/bar" /> - </services> -</routing> -- - - -
- Contained in routing. - Specifies a routing table for a specific protocol. -
-Attribute | Required | Value | Default | Description |
---|---|---|---|---|
protocol | -required | -- | - | Configure which protocol to use. - Only the protocol document is defined, - so if you define a routing table for an unsupported protocol, - the application will just log an INFO entry that contains the name of that protocol. |
verify | -optional | -boolean | -- | ToDo: document this |
Optional subelements:
- -Example:
--<routing version="1.0"> - <routingtable protocol="document"> - <route name="route1" hops="hop1 hop2" /> - <hop name="hop1" selector="docproc/cluster.foo/docproc/*/feed-processor"> - <recipient session="docproc/cluster.foo/docproc/*/feed-processor" /> - </hop> - </routingtable> -</routing> -- - - -
- Contained in routingtable. - Specifies a route for a message to its destination through a set of intermediate hops. - If at least one hop in a route does not exist, - the application will fail to start and issue an error that contains the name of that hop. -
-Attribute | Required | Value | Default | Description |
---|---|---|---|---|
name | -required | -- | - | Route name. |
hops | -required | -- | - | A whitespace-separated list of hop names, where each name must be a valid hop. |
Subelements: none
-Example:
--<routing version="1.0"> - <routingtable protocol="document"> - <route name="route1" hops="hop1 hop2" /> - <route name="route2" hops="hop3 hop4 hop5" /> - </routingtable> -</routing> -- - - -
- Contained in routingtable. - Specifies a single hop that can be used to construct one or more routes. - A hop must have a name that is unique within the routing table to which it belongs. - A hop contains a selector string and a list of recipient sessions. -
-Attribute | Required | Value | Default | Description |
---|---|---|---|---|
name | -required | -- | - | Hop name. |
selector | -required | -- | - | Selector string. |
ignore-result | -optional | -- | - | If set to true, specifies that the result of routing through that hop should be ignored. |
Optional subelements:
-Example:
--<routing version="1.0"> - <routingtable protocol="document"> - <hop name="hop1" selector="docproc/cluster.foo/docproc/*/feed-processor"> - <recipient session="docproc/cluster.foo/docproc/*/feed-processor" /> - </hop> - </routingtable> -</routing> -- - - -
- Contained in hop. - Specifies a recipient session of a hop. -
-Attribute | Required | Value | Default | Description |
---|---|---|---|---|
session | -required | -- | - | This attribute must correspond to a running instance of a - service that can be routed to. - All session identifiers consist of a location part and a - name. A search node is always given a session name on the form - search/cluster.name/g#/r#/c#/feed-destination, - whereas a document processor service is always named - docproc/cluster.name/docproc/#/feed-processor. |
Subelements: none
-Example:
--<routing version="1.0"> - <routingtable protocol="document"> - <hop name="search/cluster.music" selector="search/cluster.music/[SearchGroup]/[SearchRow]/[SearchColumn]/feed-destination"> - <recipient session="search/cluster.music/g0/c0/r0/feed-destination" /> - <recipient session="search/cluster.music/g0/c0/r1/feed-destination" /> - <recipient session="search/cluster.music/g1/c0/r0/feed-destination" /> - <recipient session="search/cluster.music/g1/c0/r1/feed-destination" /> - </hop> - </routingtable> -</routing> -- - - -
- Contained in routing. - Specifies a set of services available for a specific protocol. - At the moment the only supported protocol is document. - The services specified are used by the route verification step - to allow hops and routes to reference services known to exist, - but that can not be derived from services.xml. -
-Attribute | Required | Value | Default | Description |
---|---|---|---|---|
protocol | -required | -- | - | Configure which protocol to use. Only the protocol document is defined. |
Optional subelements:
-Example:
--<routing version="1.0"> - <services protocol="document"> - <service name="foo/bar" /> - </services> -</routing> -- - - -
- Contained in services. - Specifies a single known service that can not be derived from the services.xml. -
-Attribute | Required | Value | Default | Description |
---|---|---|---|---|
name | -required | -- | - | The name of the service. |
Subelements: none
-Example:
--<routing version="1.0"> - <services protocol="document"> - <service name="foo/bar" /> - </services> -</routing> -diff --git a/en/reference/vespa-cmdline-tools.html b/en/reference/vespa-cmdline-tools.html index e4a6dc36c9..ae92139ae1 100644 --- a/en/reference/vespa-cmdline-tools.html +++ b/en/reference/vespa-cmdline-tools.html @@ -2685,7 +2685,7 @@
- The content policy can be configured to + The content policy can be configured to use a set of configuration servers from another cluster to configure itself. This is specified with the config parameter. As an example, the following route routes to the content cluster