Evaluation of thrift

[Zhan Xu <zh...@gmail.com>]

Dear all,

I am doing evaluation of Thrift to see whether it can fit into our
production development. The following are some evaluation questions
with my answers. Since I'm pretty new to Thrift, I'd like to post my
answers to the mailing list so that experts here can correct me in
case my answers are wrong.

1. Language support:	Does it support C/C++, Java, .NET?  Does it
support JavaScript, ActionScript, or Silverlight? What other languages
does it support?  Can it be extended to new languages?
A: Supported language: C/C++, Java, C#. No Javascript, ActionScript or
Silverlight support. Other supported languages are Perl, Python, Ruby,
Smalltalk, Cocoa, Haskell, OCaml, PHP etc. To extend to other
languages, the thrift code generator should be modified and the
corresponding library for the target language should be created.

2. Message Exchange:	Does it support asynchronous messages or
synchronous send and receive style messaging?  What mechanism is used
to correlate asynchronous messages?  Can synchronous message timeouts
be controlled?
A: Thrift support synchronous messaging only. The timeout value can be
controlled through getter/setter.

3. Fault handling	Does it support custom application level faults?
How are exceptions in service logic handled back at the client?  How
are infrastructure faults handled?
A: Yes, thrift supports custom application level faults/exceptions.
Exceptions are  treated as special struct. The exceptions will be
mapped back to the target language exceptions. Thrift provide logging
mechanism(TFileTransport,StatsProcessor...) to report infrastructure
faults.

4. Extensibility	What are the extensibility points? Can the underlying
transport runtime be replaced with a different layer? Can the
proxy/stub code generator be modified?  Can we define our own base
classes for the generated proxies and stubs?
A: Thrift defines interfaces for TTransport, TProtocol, TProcessor,
TServer. To extend, we need to create classes to implement those
interfaces. The transport runtime can be replaced with a different
layer. However, for each target language, we must provide the
corresponding implementation -- the transportation is handled by
native language instead a common library. The code generator can be
modified. We can not define our own base classes for the generated
proxies and stubs unless we change the generator's code.

5. Service description language		Is the service description language
extensible with our own attributes?  Is it XML based or is it oriented
to a developer?  Is there any tooling for authoring the service
description language?
A: No, we can not extend the IDL with our own attributes. It is RPC
based. No tooling provided.

6. Versioning	How is the versioning of services handled?  Can old
clients interact with new service definitions?  Can new clients
interact with older service definitions?
A: Versioning is provided by defining field version number. However,
it does not provide versioning of the service contract. Old clients
can interact with new service. It's dangerous for new clients to
interact with old service.

7. Data type support	How rich of data type support does it provide?
Does it support "AnyType (Variant)" types?  Does it support complex
types such as lists, sets, and maps?  Does it introduce its own names
for language types or use the intrinsic types of the language?
A: Thrift supports the following types: Base types (bool, byte, i16,
i32, i64,double, string), Special types (binary), Structs without
inheritance, Containers(list, set, map), Exceptions, and Services.
AnyType may be mapped to binary type. It maps these supported types
to the target language's intrinsic types.

Other things to consider:
1) Platform support -- Windows, Linux, Mac, etc.  (Thrift -- C++ does
not work under Win)
2) Security support (Thrift -- nothing)
3) Diagnostics (Thrift -- yes, diagnostics is provided)
4) Reconnection/Takeover support (Thrift -- no, Thrift does not
support reconnection, service take over)

Thanks a lot!

BTW, I would like to say 'Thank you' for all the replies regarding my
previous question about 'Windows support'.

Zhan Xu

Re: Evaluation of thrift

[Ted Dunning <te...@gmail.com>]

Asynchronous messages are definitely supported.  I use them for logging by
sending asynchronous messages to a disk transport.  Since the actual server
doesn't receive the requests for hours, I can say for sure that the client
is definitely not blocked waiting.

On Wed, Feb 18, 2009 at 6:06 AM, Zhan Xu <zh...@gmail.com> wrote:

> A: Thrift support synchronous messaging only. The timeout value can be
> controlled through getter/setter.
>



-- 
Ted Dunning, CTO
DeepDyve

Re: Evaluation of thrift

[Ted Dunning <te...@gmail.com>]

I think that you have this exactly backwards.

Thrift is intended for very large applications involving many services
running on even more machines.

Atomic upgrades are just not possible in such an environment.  It is
therefore critical to provide for ways for old/new clients to interact with
old/new services.  Thrift actually does this extremely well and provides
some really good methods for doing rolling upgrades in a fairly seamless
manner.

I agree that it is usually good for services to lead clients in terms of
upgrades so that you only have to deal with backward compatibility on the
service side rather than on both sides, but handling all four cases in the
cross product of (old + new client) x (old + new service) is sometimes
really important.  Thrift allows this.  Systems with more intricate service
contracts generally make this *really* hard.

On Wed, Feb 18, 2009 at 6:06 AM, Zhan Xu <zh...@gmail.com> wrote:

> 6. Versioning   How is the versioning of services handled?  Can old
> clients interact with new service definitions?  Can new clients
> interact with older service definitions?
> A: Versioning is provided by defining field version number. However,
> it does not provide versioning of the service contract. Old clients
> can interact with new service. It's dangerous for new clients to
> interact with old service.
>



-- 
Ted Dunning, CTO
DeepDyve

Re: Evaluation of thrift

[Ted Dunning <te...@gmail.com>]

These are better handled at the transport level and it isn't hard to do with
thrift.

On Wed, Feb 18, 2009 at 6:06 AM, Zhan Xu <zh...@gmail.com> wrote:

> 2) Security support (Thrift -- nothing)
> ...
>
4) Reconnection/Takeover support (Thrift -- no, Thrift does not
> support reconnection, service take over)
>



-- 
Ted Dunning, CTO
DeepDyve

111 West Evelyn Ave. Ste. 202
Sunnyvale, CA 94086
www.deepdyve.com
408-773-0110 ext. 738
858-414-0013 (m)
408-773-0220 (fax)

Re: Evaluation of thrift

[Ted Dunning <te...@gmail.com>]

Uh.... you have the source.  Of *course* you can extend the language.

And the opposition of XML based versus RPC based seems very strange.  One is
syntax, the other is implementation or design philosophy.

On Wed, Feb 18, 2009 at 6:06 AM, Zhan Xu <zh...@gmail.com> wrote:

>
> 5. Service description language         Is the service description language
> extensible with our own attributes?  Is it XML based or is it oriented
> to a developer?  Is there any tooling for authoring the service
> description language?
> A: No, we can not extend the IDL with our own attributes. It is RPC
> based. No tooling provided.




-- 
Ted Dunning, CTO
DeepDyve

111 West Evelyn Ave. Ste. 202
Sunnyvale, CA 94086
www.deepdyve.com
408-773-0110 ext. 738
858-414-0013 (m)
408-773-0220 (fax)

Re: Evaluation of thrift

[Ted Dunning <te...@gmail.com>]

This sounds like a bit of a misunderstanding even if it is strictly true (I
am reading base classes as meaning primitive type).  You can definitely
define your own structures in thrift.  They won't be the standard objects
that you already use because of the cross language requirement.

On Wed, Feb 18, 2009 at 6:06 AM, Zhan Xu <zh...@gmail.com> wrote:

> We can not define our own base classes for the generated
> proxies and stubs unless we change the generator's code.
>



-- 
Ted Dunning, CTO
DeepDyve

Re: Evaluation of thrift

[Garrett Smith <g...@rrett.us.com>]

----- "Zhan Xu" <zh...@gmail.com> wrote:

> 2. Message Exchange:	Does it support asynchronous messages or
> synchronous send and receive style messaging?  What mechanism is used
> to correlate asynchronous messages?  Can synchronous message timeouts
> be controlled?
> A: Thrift support synchronous messaging only. The timeout value can
> be controlled through getter/setter.

The IDL supports an 'async' modifier. I believe this is illustrated in the tutorial sample.

Garrett