[infinispan-issues] [JBoss JIRA] Commented: (ISPN-878) update documentation for http://community.jboss.org/wiki/MultipleTiersofCaches

[Mircea Markus (JIRA)]

    [ https://issues.jboss.org/browse/ISPN-878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12603245#comment-12603245 ] 

Mircea Markus commented on ISPN-878:
------------------------------------

updated.

> update documentation for  http://community.jboss.org/wiki/MultipleTiersofCaches
> -------------------------------------------------------------------------------
>
>                 Key: ISPN-878
>                 URL: https://issues.jboss.org/browse/ISPN-878
>             Project: Infinispan
>          Issue Type: Task
>            Reporter: Mircea Markus
>            Assignee: Mircea Markus
>             Fix For: 5.0.0.FINAL
>
>
> Update http://community.jboss.org/wiki/MultipleTiersofCaches as follows:
> Feedback from Galder: though, the text in the diagram is very very small and can hardly be read. Maybe you can improve it a little?
> Feedback from Manik: 
> Also some more feedback:
> * Spelling: "Multi-Tiered", not "Multiered" 
> * Your diagram probably wants to demonstrate 2 separate tiers, not just 1 client with a clustered server backend.  E.g.,
> FE1 --- FE2 --- FE3
> ===============
> BE1 --- BE2 --- BE3
> where FE = front-end servers (embedded, maybe an app server running a webapp, with an embedded Infinispan instance as a "near cache")
> BE = backend, dedicated cache tier, running Hot Rod endpoints
> FE configured with RemoteCacheStore, and also using Invalidation so that FE's can invalidate each other
> BE's running DIST for max addressable space + ultimate scalability
> This way, with the FE's running in INVAL mode, it doesn't matter if the BE's cannot communicate changes back to the FE's, since the FE's wil already know about changes and will invalidate accordingly.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira