<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Dec 16, 2009, at 12:08 PM, Manik Surtani wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 16 Dec 2009, at 11:54, Mircea Markus wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Dec 16, 2009, at 9:26 AM, Galder Zamarreno wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><br><br>On 12/15/2009 01:13 PM, Manik Surtani wrote:<br><blockquote type="cite">A few comments:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">- Why do you have OpCode in your response header? Surely this is redundant? If the client is sync, it knows what it sent. If it is async, it has a message ID.<br></blockquote><br>True, I fixed that.<br><br><blockquote type="cite">- 'Not So Dumb' and 'Clever' response headers should be optional? Surely this stuff is only sent when there is a topology change? We also may need some extra info here - how does the back-end know to send this info? If a client hits different back-end nodes, and there is a topology change, how does Node A decide that it should not bother with topology info since the client already hit Node B after the topo change and has the new topology map? Perhaps a TopologyVersion (== JGroups View ID) should be sent back with any topo map, and the client would send it's current TopologyVersion with every request (non-dumb clients only)? Could be a vlong...<br></blockquote><br>Yeah, as you and Mircea suggest, clients sending the view id could help <br>better manage size of responses.<br><br>Something to note here is that not all cluster view changes necessarily <br>involve a client side topology view change, cos if you have N infinispan <br>nodes in the cluster, you could have M running hot rod server where M <= <br>N. So, Hot rod will need to figure out when there's been a view change <br>in the cluster that involves the addition or removal of a hot rod <br>running Infinispan instance (similar thing to what happens when a <br>clustered EJB is deployed, the target list for that clustered EJB gets <br>updated).<br></div></blockquote>yep, that's a good point. Every Hotrod server has to know exactly what other hotrod server are there running. I assume that because one way or the other each hotrod node will have to piggyback the list of active hotrod servers to the clients.</div></div></blockquote><div><br></div><div>Yes, nodes that are not running HotRod are removed from the list prior to transmission.</div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div> Can't the hotrod server track the topology changes (topology of hot rod servers) and increase the view id number at that time only?</div></div></blockquote><div><br></div><div>That would be reimplementing a lot of logic that is already in JGroups. Maintaining view IDs is non-trivial if (a) any node can update this and (b) this needs to be kept coherent even as nodes leave/join (including any node maintaining this state).</div></div></div></blockquote>some logic will need to be there to make the difference between an jgroups node leaving and a an jgroups node where hotrod is deployed leaving. Each HR server will need to know the other HR servers running (different from jgroups level view), so we already have some view management logic. </div><div><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Actually I think it can also rely on the jgroups view id, but only update the hotrod-view-id when jgroups cluster change overlaps with hotrod cluster change (i.e. a infinispan instance that has a hotrod serv started is added or removed). <br></div></div></blockquote><div><br></div><div>Precisely.</div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><blockquote type="cite"><div>So, bearing in mind this, could we just use the JGroups view id for <br>this? AFAIK, it's 0 based long but shouldn't cause problems with <br>complete cluster restarts. If the whole cluster gets restarted, existing <br>connections will be closed and at that point, clients could revert back <br>to trying to connect one of their known hot rod servers and pass -1</div></blockquote>wouldn't they pass the old view Id at this time rather than -1? Guess the client will realize that the Socket is closed, and at that time will send an "I don't have view" request, i.e. -1?<br></div></div></blockquote><div><br></div><div>No, socket being closed doesn't mean your view is out of date - it just means you fail over to the next server. A socket could close for reasons other than a server leaving the group.</div><br><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><blockquote type="cite"><div> as <br>view id which means that I have no view, so the responding server would <br>send back the hot rod cluster view.</div></blockquote><blockquote type="cite"><div><br>I'll add this to the wiki.<br></div></blockquote><div><br></div><blockquote type="cite"><div><font class="Apple-style-span"><br></font><blockquote type="cite"><br></blockquote><blockquote type="cite">Cheers<br></blockquote><blockquote type="cite">Manik<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">On 14 Dec 2009, at 20:08, Galder Zamarreno wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">Hi all,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Re: <a href="http://community.jboss.org/wiki/HotRodProtocol">http://community.jboss.org/wiki/HotRodProtocol</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I've updated the wiki with the following stuff:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">- Renamed replaceIfEquals to replaceIfUnmodified<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">- Added remove and removeIfUnmodified.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">- Added containsKey command.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">- Added getWithCas command so that cas value can be returned. I decided<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">for a separate command rather than adding cas to get return because you<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">don't always want cas to be returned. Having a separate command makes<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">better use of network bandwith.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">- Added stats command. JMX attributes are basically accessible through<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">this, including cache size.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">- Added error handling section and updated status codes.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Note that Mircea added some interesting comments and I replied to them<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">directly in the wiki.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Still remaining to add:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">- Commands: putForExternalRead evict, clear, version, name and quite<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">commands.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">- Passing flags.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Regards,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">p.s. Updating this has been quite a struggle due to F12 + FF 3.5.5<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">crashing at least 5 times, plus parts of the wiki dissapearing after<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">publishing them!<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">--<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Galder Zamarreņo<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Sr. Software Engineer<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Infinispan, JBoss Cache<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">_______________________________________________<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">infinispan-dev mailing list<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">--<br></blockquote><blockquote type="cite">Manik Surtani<br></blockquote><blockquote type="cite"><a href="mailto:manik@jboss.org">manik@jboss.org</a><br></blockquote><blockquote type="cite">Lead, Infinispan<br></blockquote><blockquote type="cite">Lead, JBoss Cache<br></blockquote><blockquote type="cite"><a href="http://www.infinispan.org/">http://www.infinispan.org</a><br></blockquote><blockquote type="cite"><a href="http://www.jbosscache.org/">http://www.jbosscache.org</a><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">infinispan-dev mailing list<br></blockquote><blockquote type="cite"><a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br></blockquote><blockquote type="cite"><a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br></blockquote><br>-- <br>Galder Zamarreņo<br>Sr. Software Engineer<br>Infinispan, JBoss Cache<br>_______________________________________________<br>infinispan-dev mailing list<br><a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br><a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br></div></blockquote></div><br></div>_______________________________________________<br>infinispan-dev mailing list<br><a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br><a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a></blockquote></div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; 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; "><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; 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; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>--</div><div>Manik Surtani</div><div><a href="mailto:manik@jboss.org">manik@jboss.org</a></div><div>Lead, Infinispan</div><div>Lead, JBoss Cache</div><div><a href="http://www.infinispan.org/">http://www.infinispan.org</a></div><div><a href="http://www.jbosscache.org/">http://www.jbosscache.org</a></div><div><br></div></div></span><br class="Apple-interchange-newline"></span><br class="Apple-interchange-newline">
</div>
<br></div>_______________________________________________<br>infinispan-dev mailing list<br><a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>https://lists.jboss.org/mailman/listinfo/infinispan-dev</blockquote></div><br></body></html>