<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Dec 2, 2013 at 11:44 AM, Galder Zamarreño <span dir="ltr">&lt;<a href="mailto:galder@redhat.com" target="_blank">galder@redhat.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
On Nov 27, 2013, at 3:06 PM, Mircea Markus &lt;<a href="mailto:mmarkus@redhat.com">mmarkus@redhat.com</a>&gt; wrote:<br>
<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt;&gt; - how does the server know that a request originated from a certain client in order not to send it to that client again? There&#39;s no clientId in the request…<br>
&gt;&gt;<br>
&gt;&gt; Well spotted :). There are two ways to solve this.<br>
&gt;&gt;<br>
&gt;&gt; First one is by adding the source id to each cache operation sent from the client. This would require a change in the way the header is parsed for all operations. This is the simplest solution, with a little addition to the header.<br>


&gt;&gt;<br>
&gt;&gt; The second option is a bit more complicated but avoids the need to send the source id per request. At least in the Java client, each connection opened sends a ping at the start. You could add source id to the ping command, and then the server could track all incoming connections that send a particular id. There could be multiple in the case of clients pooling connections. The server can track disconnections and keep this collection up to date, but it&#39;d be quite a bit of work on top of the rest of stuff.<br>


&gt;&gt;<br>
&gt;&gt; I&#39;d prefer the first option.<br>
&gt;<br>
&gt; +1, for simplicity. We also don&#39;t enforce the client connections to start with a ping either.<br>
<br>
</div>^ Indeed we don&#39;t. It&#39;s something the java client does by default but it&#39;s not mandatory at all.<br>
<div class="im"><br>
&gt; How would you generate the client id? ip+port perhaps? or something the server would issue (shared server counter) when a client asks for it?<br>
<br>
</div>The client or source id should ideally be composed of two parts:<br>
1. Something the Hot Rod client provides via configuration.<br>
2. Something that&#39;s dynamically generated whenever the RemoteCacheManager is started.<br>
<br>
The former could be anything from a simple application id, to an application id alonside client host and port. This is the static part of the source or client id. The one that&#39;s always the same for a RemoteCacheManager unless the configuration changes. The second part, which is dynamic, should be created by the Hot Rod client implementation in order to avoid client resurrection issues (a similar method to what JGroups does).<br>


<br>
Regardless, the source or client id will be a variable length byte array.<br>
<br>
I think this is easier than relying in some kind of server side state, and having to synch that. You could have many clients connecting, so having to produce something different for each, cluster wide, could be challenging.<br>


<br>
Thoughts?<br></blockquote><div><br></div><div>Why not a UUID?<br><br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; Cheers,<br>
&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; On Nov 12, 2013, at 3:17 PM, Galder Zamarreño &lt;<a href="mailto:galder@redhat.com">galder@redhat.com</a>&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Hi all,<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Re: <a href="https://github.com/infinispan/infinispan/wiki/Remote-Hot-Rod-Events" target="_blank">https://github.com/infinispan/infinispan/wiki/Remote-Hot-Rod-Events</a><br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; I&#39;ve just finished writing up the Hot Rod remote events design document. Amongst many other use cases, this will enable near caching use cases with the help of Hot Rod client callbacks.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Cheers,<br>
&gt;&gt;&gt;&gt; --<br>
&gt;&gt;&gt;&gt; Galder Zamarreño<br>
&gt;&gt;&gt;&gt; <a href="mailto:galder@redhat.com">galder@redhat.com</a><br>
&gt;&gt;&gt;&gt; <a href="http://twitter.com/galderz" target="_blank">twitter.com/galderz</a><br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Project Lead, Escalante<br>
&gt;&gt;&gt;&gt; <a href="http://escalante.io" target="_blank">http://escalante.io</a><br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Engineer, Infinispan<br>
&gt;&gt;&gt;&gt; <a href="http://infinispan.org" target="_blank">http://infinispan.org</a><br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt;&gt; infinispan-dev mailing list<br>
&gt;&gt;&gt;&gt; <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
&gt;&gt;&gt;&gt; <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Cheers,<br>
&gt;&gt;&gt; --<br>
&gt;&gt;&gt; Mircea Markus<br>
&gt;&gt;&gt; Infinispan lead (<a href="http://www.infinispan.org" target="_blank">www.infinispan.org</a>)<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt; infinispan-dev mailing list<br>
&gt;&gt;&gt; <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
&gt;&gt;&gt; <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; --<br>
&gt;&gt; Galder Zamarreño<br>
&gt;&gt; <a href="mailto:galder@redhat.com">galder@redhat.com</a><br>
&gt;&gt; <a href="http://twitter.com/galderz" target="_blank">twitter.com/galderz</a><br>
&gt;&gt;<br>
&gt;&gt; Project Lead, Escalante<br>
&gt;&gt; <a href="http://escalante.io" target="_blank">http://escalante.io</a><br>
&gt;&gt;<br>
&gt;&gt; Engineer, Infinispan<br>
&gt;&gt; <a href="http://infinispan.org" target="_blank">http://infinispan.org</a><br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; infinispan-dev mailing list<br>
&gt;&gt; <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
&gt;&gt; <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
&gt;<br>
&gt; Cheers,<br>
&gt; --<br>
&gt; Mircea Markus<br>
&gt; Infinispan lead (<a href="http://www.infinispan.org" target="_blank">www.infinispan.org</a>)<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; infinispan-dev mailing list<br>
&gt; <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
&gt; <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
<br>
<br>
--<br>
Galder Zamarreño<br>
<a href="mailto:galder@redhat.com">galder@redhat.com</a><br>
<a href="http://twitter.com/galderz" target="_blank">twitter.com/galderz</a><br>
<br>
Project Lead, Escalante<br>
<a href="http://escalante.io" target="_blank">http://escalante.io</a><br>
<br>
Engineer, Infinispan<br>
<a href="http://infinispan.org" target="_blank">http://infinispan.org</a><br>
<br>
<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" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
</div></div></blockquote></div><br></div></div>