[infinispan-dev] ISPN-29 and a "custom protocol"

Galder Zamarreno galder at redhat.com
Fri Nov 20 05:50:14 EST 2009 

Hi Alex,

On 11/19/2009 06:02 PM, Alex Kluge wrote:
> Hi,
>
>   >  Is this protocol documented somewhere?
>
>   Putting this online is one of the main things I will be able to do
>   along this path over the next week.
>
>   >  Galder is working on the HotRod protocol which may well benefit
>   >  from this.
>
>   Well, it may not be necessary to reinvent it. We'll see. Are there
>   requirements for an infinispan protocol documented anywhere?

Manik and I discussed the extra bits that we think the binary protocol 
should contain and these are now explained in: 
http://www.jboss.org/community/wiki/HotRodProtocol

If you can add docu of your binary protocol there, we can look into 
accomodation this stuff into your binary protocol potentially?

>
>   >  The plan is for HotRod to support (but not mandate)
>   >  client-side CH
>
>   I did this originally, however, I moved to a server side message
>   routing for a few reasons.
>
>   - It is easier to coordinate the smaller number of servers when a new
>     one comes online, or goes offline.

Hmmmm, I'm not sure I understand why this would be a problem for client 
side routing. The client's would get new cluster formation information 
next time they make a call. IOW, the response to the client would 
contain cluster formation info of the nodes configured with hot rod 
server, so no need to coordinate server join/leaves with clients. This 
is how clustered EJBs work in AS.

>
>   - It allows fewer connections per server, client side routing requires
>     that each client connect to each server. For our scale, thousands of
>     servers, this is an issue.

That's a good point.

>
>   - It guarantees a consistent mapping of data to servers for potentially
>     disperate clients.
>
>   - It makes the client side code easier to write.

True :)

>
>
>   That said, if the client does do the hashing, the server will still
>   do it, and make sure that the data arrives at the correct server. So
>   nothing prevents the client from doing the hashing.
>
>                                            Alex
>
>
> --- On Mon, 11/16/09, Manik Surtani<manik at jboss.org>  wrote:
>
>> From: Manik Surtani<manik at jboss.org>
>> Subject: Re: [infinispan-dev] ISPN-29 and a "custom protocol"
>> To: "infinispan -Dev List"<infinispan-dev at lists.jboss.org>
>> Date: Monday, November 16, 2009, 5:06 AM
>> Hi Alex - comments in line:
>>
>> On 16 Nov 2009, at 07:25, Alex Kluge wrote:
>>
>>> Hi,
>>>
>>>    It is worth mentioning that I have a full
>> implementation of a
>>> client-server binary protocol used for jboss-cache,
>> which is similar
>>> to the current project and can be easily adapted to
>> it. There are a
>>> number of interesting points
>>>
>>>     - Built on Apache MINA framework, but
>> the layers are well separated,
>>>       so replacing one would not be
>> too difficult.
>>
>> Nice.
>>
>>>     - Language neutral binary protocol
>> (non Java clients are planned).
>>
>> Is this protocol documented somewhere?  Galder is
>> working on the HotRod protocol which may well benefit from
>> this.
>>
>>>     - Integrated into Jboss Cache as an
>> L2 cache, but easily used
>>>       independently.
>>>     - Performance is quite reasonable,
>> with request/response cycles on
>>>       the order of 600 microseconds
>> for small request/response.
>>>     - Easily extensible, a different
>> codec can be supplied to support
>>>       different protocols. Some
>> refactoring could be done to make this
>>>       much easier.
>>>     - Non trivially tested already.
>>>     - Inherently asynchronous -
>> synchronous responses are achieved by
>>>       immediately waiting on the
>> response future object.
>>>     - Server side consistent hashing,
>> clients connect to any server.
>>
>> The plan is for HotRod to support (but not mandate)
>> client-side CH as well for "smart" connections.
>>
>>> There is raw source at
>>>     http://www.vizitsolutions.com/org.jboss.cache.tcpcache.tar.gz
>>>
>>> I'll see about some explanations and examples over the
>> next weeks.
>>
>> Great!
>>
>>> This was intended to be contributed back to the Jboss
>> Cache project from the beginning, hence the organization
>> into jboss.cache packages. Oh, and
>>> I never gave it a snazzy name - I just called it the
>> Jboss Cache binary
>>> protocol.
>>
>> :)
>>
>>
>>>
>>>
>>
>>      Alex
>>>
>>> --- On Wed, 8/19/09, Manik Surtani<manik at jboss.org>
>> wrote:
>>>
>>>> From: Manik Surtani<manik at jboss.org>
>>>> Subject: Re: [infinispan-dev] ISPN-29 and a
>> "custom protocol"
>>>> To: "Jeff Ramsdale"<jeff.ramsdale at gmail.com>
>>>> Cc: infinispan-dev at lists.jboss.org
>>>> Date: Wednesday, August 19, 2009, 12:05 PM
>>>> Nice one Jeff ... so far this is
>>>> winning in my mind!
>>>>
>>>> On 19 Aug 2009, at 18:01, Jeff Ramsdale
>>>> wrote:
>>>> How about Hot Rod? It has a connection to the
>>>> word "custom" and implies speed...
>>>> -jeff
>>>>
>>>> On Wed, Aug 19, 2009 at 7:05 AM,
>>>> Manik Surtani<manik at jboss.org>
>>>> wrote:
>>>> Regarding
>>>> ISPN-29 [1], I've made some notes about what this
>> will
>>>> provide on this wiki page [2].  I'm kinda
>> tired
>>>> of referring to the
>>>> 'custom binary protocol' as a 'custom binary
>>>> protocol'!  Can anyone
>>>> think of a snazzy name for this protocol?
>> Keep in
>>>> mind that we would
>>>> want others to implement clients using this
>> protocol as
>>>> well on other
>>>> platforms.
>>>>
>>>> Here are a few thoughts to get the creative
>> juices
>>>> flowing:
>>>>
>>>>          * ICBP (Infinispan
>> cache binary
>>>> protocol - BORING!)
>>>>          * Adhesive (the 'glue'
>>>> between the client and server)
>>>>          * Elastiglue
>>>>          * StickyFingers (after
>> the
>>>> Rolling Stones album?)
>>>>
>>>> - Manik
>>>>
>>>> [1] https://jira.jboss.org/jira/browse/ISPN-29
>>>> [2] http://www.jboss.org/community/wiki/Clientandservermodules
>>>> --
>>>> Manik Surtani
>>>> manik at jboss.org
>>>> Lead, Infinispan
>>>> Lead, JBoss Cache
>>>> http://www.infinispan.org
>>>> http://www.jbosscache.org
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> infinispan-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>
>>>>
>>>> --Manik
>>>> Surtanimanik at jboss.orgLead,
>>>> InfinispanLead, JBoss Cachehttp://www.infinispan.orghttp://www.jbosscache.org
>>>>
>>>>
>>>>
>>>>
>>>> -----Inline Attachment Follows-----
>>>>
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> infinispan-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>> --
>> Manik Surtani
>> manik at jboss.org
>> Lead, Infinispan
>> Lead, JBoss Cache
>> http://www.infinispan.org
>> http://www.jbosscache.org
>>
>>
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

-- 
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache

More information about the infinispan-dev mailing list