On 17 Jun 2011, at 13:49, Mircea Markus wrote: > >> But yes, there is no reason why we can't replace this with RPC as per >> Distribution, however I think we do need a streaming solution - not just for >> replication but distribution as well. As such I'd only want to re-implement >> this bit once, rather than a temp RPC based solution first. So we need a >> mechanism to either: > Now this might sound a bit too radical but do we really need REPLICATED mode?
Yes. :-) REPL is ideal for certain common usage patterns: read-heavy, small clusters (under 10 nodes), small overall data volume (fits in any single JVM's heap). This gives fast reads since reads are always local, etc. > This is not fully brewed, but if e.g. we set numOwners = Integer.MAX_INTEGER > the cluster is effectively in replicated mode, so can't we just drop the > REPLICATION entirely? This would reduce the code size significantly... We could in theory achieve this as you suggest with numOwners = MAX_INTEGER, but internally we'd still be best off implementing this as we have right now. Saves on a lot of overhead (memory as well as processing) compared to a DIST-like setup with an unlimited number of data owners. >> >> (1) open a separate TCP socket for the sake of streaming state, or >> (2) reuse the sockets JGroups opens. >> They both have their pros and cons. >> >> (1) is more configuration, firewall setup, and a spiderweb of connections in >> a large grid >> (2) would mean multiplexing with JGroups' use of the socket. > Having our own sockets might cause an administration complications. Also > borrowing sockets from jgroups doesn't seems nice...I'm not a fan of either > solution really: I think this should be transport's responsibility and we > should enhance jgroups to offer the streaming service. Yes, it would be implemented in our Transport abstraction, for sure. So code wouldn't leak, but all the same there is no hard requirement that JGroups provides this (since it could be impl'd in JGroupsTransport). -- Manik Surtani ma...@jboss.org twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org
_______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
