Mailing-List: contact cassandra-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cassandra-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of avinash.lakshman@gmail.com
 designates 209.85.146.179 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=NWB/8CHBeIbOcfwMle3+7aA3TPDJF14C4vLrXiMcPIfOBxJ0BGGfbufWT5/Hs5KP9t
         zQWQMonjItZFmPGRnxXNV0LP6+nWHXZam2Q2nuvPf2/fo+uwhqfcn28phBveOHw/3ti6
         CiefHpjLA1ilvRN+MpoRJOA1G9kkTWKoACOh4=
MIME-Version: 1.0
In-Reply-To: <e06563880903280948v3dd7bbd4t877d9eed94797926@mail.gmail.com>
References: <e06563880903280811o6588e1edu51e8433591dc478e@mail.gmail.com>
	 <a06de5520903280934jae6b13btff59ca50e1038fd9@mail.gmail.com>
	 <e06563880903280948v3dd7bbd4t877d9eed94797926@mail.gmail.com>
Date: Sat, 28 Mar 2009 10:39:56 -0700
Message-ID: <a06de5520903281039u47582baek63ed22d92ff6ebdf@mail.gmail.com>
Subject: Re: Message classes
From: Avinash Lakshman <avinash.lakshman@gmail.com>
To: cassandra-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=00163645767a738c24046631566c

--00163645767a738c24046631566c
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

For eg Thrift will definitely not help in the messages that we use for the
membership protocol. Because there we need to control how big the serialized
messages are - we make sure we serialize a part of the object such that it
fits into an ethernet MTU packet. We do this so that we don't get bitten by
UDP fragmentation. I don't think you could do operations like that in Thrift
based serialization mechanism. We need more control over the serialization
mechanism.

So I don't know if this is something that is insanely important in any
capacity in my opinion. I am sure there are bunch of other reasons I can
come up with - we went through this exercise 2 year back. Of course if you
want to investigate the efficacy I can't stop you from doing so :).

Avinash

On Sat, Mar 28, 2009 at 9:48 AM, Jonathan Ellis <jbellis@gmail.com> wrote:

> One point of clarification -- I don't understand why looking up by
> string is better than using an enum, for instance.  java will autobox
> enums for use in a hashmap lookup.
>
> On Sat, Mar 28, 2009 at 10:34 AM, Avinash Lakshman
> <avinash.lakshman@gmail.com> wrote:
> > Why is it ad-hoc? And it uses a factory pattern and I don't think it hard
> > once you get a hang of it. Consumers of the system are not even going to
> > know about these details. Personally I am never a fan of fixing anything
> > that is not broken - in this case it has been working really well for us.
> > This is now just a matter of what one might prefer. Thrift is something
> that
> > I would not like to see anywhere apart from the entry point. With regards
> to
> > the using the string to lookup the handlers it was done because if you
> don't
> > do that then you will have to resort to RPC style instead of message
> passing
> > or find the handlers based on the kind of messages i.e if-else branching.
> We
> > use non-blocking I/O for all our internal messaging and Thrift using
> > blocking I/O. There is big difference in throughput and also Thrift
> > non-blocking I/O from what I hear is horrendous in performance and
> > stability. My friend you don't have my vote for this :).
> > Avinash
> >
> > On Sat, Mar 28, 2009 at 8:11 AM, Jonathan Ellis <jbellis@gmail.com>
> wrote:
> >
> >> we have a Message class that mostly represents a bunch of bytes (but
> >> sometimes does not, which in some cases causes bugs) and a bunch of
> >> other *Message classes that are not Message subclasses but generate
> >> Message objects (so you have the amusingly redundant Message message =
> >> readResponseMessage.makeReadResponseMessage() in places).
> >>
> >> I think we can replace these ad-hoc and tedious-to-write Message
> >> factories with generated thrift code.  Thrift is good at this and
> >> efficient (currently our message identifiers are inefficient strings
> >> like "ROW-READ-VERB-HANDLER").
> >>
> >> Any objections to investigating replacing the hand-coded messages with
> >> thrift?
> >>
> >
>

--00163645767a738c24046631566c--