Matt Burgess created NIFI-4589:
----------------------------------
Summary: Allow multiple keys in FetchDistributedMapCache
Key: NIFI-4589
URL: https://issues.apache.org/jira/browse/NIFI-4589
Project: Apache NiFi
Issue Type: Improvement
Components: Extensions
Reporter: Matt Burgess
Currently (1.4.0) FetchDistributedMapCache will look up a single key and place
the value (if present) in either the flow file content or a user-named
attribute, depending on the value of the "Put Cache Value In Attribute"
property. If the user wishes to look up more than one value, they need multiple
FetchDistributedMapCache processors, and each would make one call to the server
to get a single key.
A useful improvement would be to allow multiple keys to be retrieved at once by
FetchDistributedMapCache. This would likely involve the following:
1) Update documentation and code to accept a comma-separated list of Cache Key
Identifiers
2) If a single Cache Key Identifier is specified, current behavior is retained
(i.e. output to flow file content or a specified attribute)
3) If multiple Cache Key Identifiers are specified, then Put Cache Value In
Attribute must be set, and the attributes will be prefixed by the value of said
property, followed by a period, followed by the evaluated cache key. So if
Cache Key Identifier is set to "field1, field2" and Put Cache Value In
Attribute is set to "myattrs", then the value for field1 will be placed in the
"myattrs.field1" attribute, and field2's value in "myattrs.field2" respectively.
4) Due to the possible presence of Expression Language in the Cache Key
Identifier property, it may not be possible to determine whether multiple cache
keys are present (i.e. a single EL function that generates a comma-separated
list), so the requirement on Put Cache Value In Attribute being set must be
checked at validation time (if possible) and also run-time
5) To make this fetch efficient, a method "subMap" can be created on the
DistributedMapCache API, so multiple keys can be passed and multiple key/value
pairs can be returned in a single call to the cache server.
6) #5 implies a new protocol version (would be 3 at the time of this writing)
be added to the DistributedMapCache API
7) If protocol negotiation results in a lower version being used, then the
client should gracefully degrade into using the "subMap" operation to make
multiple calls to the "get" operation, and fill in the result map manually.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
