On Fri, Nov 13, 2015 at 4:27 PM, Sanne Grinovero <[email protected]> wrote: > On 13 November 2015 at 14:11, Tristan Tarrant <[email protected]> wrote: >> On 13/11/2015 14:53, Gustavo Fernandes wrote: >>> Not sure about local caches, what about log retention when the node dies? >> >> I wanted a solution which can suffer splits and not adversely affect the >> cluster otherwise. But I'm open for counterarguments. > > The indexer can be a service which lives independently from > Infinispan; ELK would be one of the options, but there are others > already (JGroups, JMS). > But obviously you'd have a problem when the grid is fine, but there's > a split between the Infinispan grid and such service.. > configuring an embedded local Lucene indexer would be better. > > When using the JMS backend we have the option to store the logs > locally and replicate them to ELK when the connection to ELK is > restored; you'd need JMS for that one to work, but it should be easy > to implement a similar thing using a simplified disk journal. I guess > what I'm staying is that the Search back-end is pluggable, and having > one which tries remote first or logs to disk otherwise should be easy > (and a welcome reusable backend for other circumstances).
+1 to use a local cache by default, and maybe support additional (async) replication to another service. Tristan, can the users configure WildFly/Infinispan Server to use another logging service instead of Log4J2? If yes, perhaps implementing this functionality with custom appenders is not a good idea... Cheers Dan _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
