<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 17 Jun 2011, at 13:49, Mircea Markus wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><font class="Apple-style-span" color="#006312"><font class="Apple-style-span" color="#144FAE"><br></font></font><blockquote type="cite">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:<br></blockquote>Now this might sound a bit too radical but do we really need REPLICATED mode?<br></div></blockquote><div><br></div><div>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.</div><br><blockquote type="cite"><div>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...<br></div></blockquote><div><br></div>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.</div><div><br><blockquote type="cite"><div><blockquote type="cite"><br></blockquote><blockquote type="cite">(1) open a separate TCP socket for the sake of streaming state, or<br></blockquote><blockquote type="cite">(2) reuse the sockets JGroups opens.<br></blockquote><blockquote type="cite">They both have their pros and cons.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">(1) is more configuration, firewall setup, and a spiderweb of connections in a large grid<br></blockquote><blockquote type="cite">(2) would mean multiplexing with JGroups' use of the socket.<br></blockquote>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.<br></div></blockquote><div><br></div><div>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).</div></div><div><br></div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div><div>--</div><div>Manik Surtani</div><div><a href="mailto:manik@jboss.org">manik@jboss.org</a></div><div><a href="http://twitter.com/maniksurtani">twitter.com/maniksurtani</a></div><div><br></div><div>Lead, Infinispan</div><div><a href="http://www.infinispan.org">http://www.infinispan.org</a></div><div><br></div></div></span><br class="Apple-interchange-newline">
</div>
<br></body></html>