You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by "Gideon (JIRA)" <ji...@apache.org> on 2017/05/16 21:32:04 UTC
[jira] [Updated] (GEODE-2932) Users would like option for PR with
empty data policy
[ https://issues.apache.org/jira/browse/GEODE-2932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gideon updated GEODE-2932:
--------------------------
Description:
Allow for accessor partitioned regions to route incoming operations.
The idea is to use a PR to control distributed/partitioned _processing_ of events without the need to cache them. This option would be especially useful for streaming cases where the target is a PR's attached AsyncEventQueue. Also useful when the target is a PR's attached CacheListener. We have developed some work-around for this in the field, but they require significant code and complex configuration, and limited to event input from peer-clients.
For many use-cases, there would still be a need to co-locate other standard/caching PR's with the "empty" one to enable enrichment, transformation, and similar logic in the custom event callbacks (either CacheListener or AEQ Listener).
was:
Allow for accessor partitioned regions to route incoming operations.
[~gideonlow] feel free to add a particular use case -- I did not catch it all.
> Users would like option for PR with empty data policy
> ------------------------------------------------------
>
> Key: GEODE-2932
> URL: https://issues.apache.org/jira/browse/GEODE-2932
> Project: Geode
> Issue Type: Improvement
> Components: regions
> Reporter: Fred Krone
>
> Allow for accessor partitioned regions to route incoming operations.
> The idea is to use a PR to control distributed/partitioned _processing_ of events without the need to cache them. This option would be especially useful for streaming cases where the target is a PR's attached AsyncEventQueue. Also useful when the target is a PR's attached CacheListener. We have developed some work-around for this in the field, but they require significant code and complex configuration, and limited to event input from peer-clients.
> For many use-cases, there would still be a need to co-locate other standard/caching PR's with the "empty" one to enable enrichment, transformation, and similar logic in the custom event callbacks (either CacheListener or AEQ Listener).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)