You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@geode.apache.org by "Bruce Schuchardt (JIRA)" <ji...@apache.org> on 2016/01/29 18:51:39 UTC

[jira] [Updated] (GEODE-395) Allow multiple caches per JVM

     [ https://issues.apache.org/jira/browse/GEODE-395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bruce Schuchardt updated GEODE-395:
-----------------------------------
    Assignee: Edin Zulich

> Allow multiple caches per JVM
> -----------------------------
>
>                 Key: GEODE-395
>                 URL: https://issues.apache.org/jira/browse/GEODE-395
>             Project: Geode
>          Issue Type: New Feature
>          Components: client/server
>            Reporter: Eric Pederson
>            Assignee: Edin Zulich
>
> In a microservices environment it is common to have services that are clients of other services.  For example, we have services that, in their client API, connect to the cluster and create a continuous query on their service's region.  The services themselves may host a peer region.
> Right now there is a limitation of one {{GemFireCache}} per JVM.  The main pain points for us with this limitation are:
> # All clients must connect to the same environment. Typically we want to connect to the same environment for most services but one or two should connect to a different environment.  For example, use UAT for most services but use Dev for a service that we are debugging.
> # All clients must be configured the same way.  For example, we cannot have two services with different PDX configurations.
> # Clients must be aware of each other so they don't try to recreate a {{ClientCache}} accidentally.
> # A peer and a client cannot live in the same JVM.  
> Currently our approach is to wrap the {{ClientCache}} as a singleton class and have the singleton manage the lifecycle of the {{ClientCache}}.  If we want to connect to multiple environments then the clients cannot expose Gemfire directly.  The service itself has to manage CQs and we proxy the CQs over JMS to the client.  CACHING_PROXY is not an option in these scenarios.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)