You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Following up on #2072 - where static configuration was added which "pre-defined" extraFields to proactively send with Thing "Events" and "Messages" in order to reduce roundtrips in the cluster to retrieve the extraFields.
It would be even better to let Ditto automatically figure out
for which namespaces
which "extraFields" are requested frequently
and pro-actively start sending them, aiming to reduce internal fetching of extraFields
Ditto could e.g. track how often a RetrieveThing command (in scope of "enrichment" - which could be identifiable via an internal header) for specific fields of a namespace is done and automatically build up a cache of "most frequently" asked for fields.
Then start to send them pro-actively as pre-defined extraFields (see #2072 for the fundamentals on that).
Reasoning of this is that e.g. connections have rather statically configured "extraFields" - and via connections Ditto most likely gets most of the "extraFields" enrichment requests.
Sporadically, also WebSocket and SSE (Server Sent Event) may ask for extraFields - but this should not be much, so ideally such things would not be pro-actively added by the mechanism (to also not send too much stuff pro-actively).
The text was updated successfully, but these errors were encountered:
Following up on #2072 - where static configuration was added which "pre-defined"
extraFields
to proactively send with Thing "Events" and "Messages" in order to reduce roundtrips in the cluster to retrieve theextraFields
.It would be even better to let Ditto automatically figure out
extraFields
Ditto could e.g. track how often a
RetrieveThing
command (in scope of "enrichment" - which could be identifiable via an internal header) for specific fields of a namespace is done and automatically build up a cache of "most frequently" asked for fields.Then start to send them pro-actively as pre-defined extraFields (see #2072 for the fundamentals on that).
Reasoning of this is that e.g. connections have rather statically configured "extraFields" - and via connections Ditto most likely gets most of the "extraFields" enrichment requests.
Sporadically, also WebSocket and SSE (Server Sent Event) may ask for
extraFields
- but this should not be much, so ideally such things would not be pro-actively added by the mechanism (to also not send too much stuff pro-actively).The text was updated successfully, but these errors were encountered: