Lines Matching full:is
12 % It is available at <http://www.sigplan.org/authorInformation.htm>.
43 Thrift is a software library and set of code-generation tools developed at
45 backend services. Its primary goal is to enable efficient and reliable
48 that is implemented in each language. Specifically, Thrift allows developers to
53 well as some of the more interesting implementation details. It is not
54 intended to be taken as research, but rather it is an exposition on what we did
90 any advanced introspective run-time type checking. It is also designed to
104 or write their own serialization code. That is,
112 transport is implemented should not matter to the service developer.
120 an XML or binary protocol is immaterial to the application code.
121 All that matters is that the data can be read and written in a consistent,
140 The goal of the Thrift type system is to enable programmers to develop using
145 Definition Language) file is
169 Of particular note is the absence of unsigned integer types. Because these
171 the advantages they afford are lost. Further, there is no way to prevent the
176 identifiers. In this case, the sign is irrelevant. Signed integers serve this
183 is essentially equivalent to a class in object oriented programming
212 only requirement is that the custom types support all the necessary iteration
237 language. Again, the design emphasis is on making the code familiar to the
242 Services are defined using Thrift types. Definition of a service is
265 Note that \texttt{void} is a valid type for a function return, in addition to
272 transport layer. (In many transport scenarios this is inherently unreliable
275 method calls are acceptable or the transport is known to be reliable.)
277 Also of note is the fact that argument lists and exception lists for functions
283 The transport layer is used by the generated code to facilitate data transfer.
288 transport layer from the code generation layer. Though Thrift is typically
304 \item \texttt{isOpen} Indicates whether the transport is open
315 \texttt{TTransport} interface, there is a\\
317 used to accept or create primitive transport objects. Its interface is as
329 The transport interface is designed for simple implementation in any
335 The \texttt{TSocket} class is implemented across all target languages. It
340 The \texttt{TFileTransport} is an abstraction of an on-disk file to a data
347 The Transport interface is designed to support easy extension using common
357 A second major abstraction in Thrift is the separation of data structure from
359 transporting data, but it is agnostic to the protocol encoding in use. That is,
360 it does not matter whether data is encoded as XML, human-readable ASCII, or a
366 The Thrift Protocol interface is very straightforward. It fundamentally
414 the exception of \texttt{writeFieldStop()}. This is a special method
415 that signals the end of a struct. The procedure for reading a struct is to
416 \texttt{readFieldBegin()} until the stop field is encountered, and then to
420 that this set of functions is by design more robust than necessary.
421 For example, \texttt{writeStructEnd()} is not strictly necessary, as the end of
422 a struct may be implied by the stop field. This method is a convenience for
423 verbose protocols in which it is cleaner to separate these calls (e.g. a closing
430 entire data length of a structure prior to encoding it. This is critical to
435 as iteration is performed, the corresponding read may begin in parallel,
436 theoretically offering an end-to-end speedup of $(kN - C)$, where $N$ is the size
438 element, and $C$ is fixed offset for the delay between data being written
448 read deterministically. The Thrift protocol is self-delimiting without any
451 In situations where streaming is unnecessary or framing is advantageous, it
458 is used by most backend services. Essentially, it writes all data
472 Thrift is robust in the face of versioning and data definition changes. This
473 is critical to enable staged rollouts of changes to deployed services. The
479 Versioning in Thrift is implemented via field identifiers. The field header
480 for every member of a struct in Thrift is encoded with a unique field
482 is used to uniquely identify the field. The Thrift definition language
483 supports automatic assignment of field identifiers, but it is good
500 When data is being deserialized, the generated code can use these identifiers
502 its definition file. If a field identifier is not recognized, the generated
504 Again, this is possible due to the fact that all datatypes are self
529 When an unexpected field is encountered, it can be safely ignored and
530 discarded. When an expected field is not found, there must be some way to
531 signal to the developer that it was not present. This is implemented via an
533 is implicit with a \texttt{null} value in PHP, \texttt{None} in Python
536 for each field which denotes whether or not that field is present in the
576 is not set, and implements default behavior for out-of-date requests.
582 \item \textit{Removed field, new client, old server.} This is the most
583 dangerous case, as the old server is unlikely to have suitable default
584 behavior implemented for the missing field. It is recommended that in this
591 see fit. Specifically, any protocol implementation is free to send whatever
592 it likes in the \texttt{writeMessageBegin()} call. It is entirely up to the
593 implementor how to handle versioning at the protocol level. The key point is
597 Note that the exact same is true of the \texttt{TTransport} interface. For
607 The last core interface in the Thrift design is the \texttt{TProcessor},
608 perhaps the most simple of the constructs. The interface is as follows:
617 The key design idea here is that the complex systems we build can fundamentally
619 most cases, there is actually just one input and output (an RPC client) that
624 When a service is defined, we generate a
626 using a few helpers. The fundamental structure (illustrated in pseudo-C++) is
651 A client class is generated, which implements the interface and
670 \texttt{TBufferedTransportFactory} is used here)
687 The \texttt{TProcessor} interface is very general by design. There is no
707 authors' opinions there is already far too much repetitive enterprise Java
719 \texttt{get()} methods. Similarly, use of the \texttt{isset} object is not
722 the system is robust to the developer ignoring the \texttt{isset} construct
726 goal is not to make developers learn a rich new library in their language of
732 of RPC clients and servers. Thrift is a useful tool simply for generating
737 issue with this approach is that longer method names require more bandwidth.
740 dealing with conflicts across versions of an interface definition file is
747 pointers, so that invocation is effectively accomplished via a constant-time
776 Using these techniques, the cost of string processing is minimized, and we
799 \texttt{boost::threadpool} is
800 not a pure template library and requires runtime libraries and because it is
802 use in Thrift. As \texttt{boost::threadpool} evolves and especially if it is
806 primitives. The biggest problem with ACE is that it is ACE. Unlike Boost, ACE
807 API quality is poor. Everything in ACE has large numbers of dependencies on
827 on Thrift. We decided to use \texttt{boost::shared\_ptr} because it is so
829 runtime libraries (i.e. it is a pure template library) and it is due
833 \texttt{Monitor} class. The latter is simply a combination of a mutex and
834 condition variable and is analogous to the \texttt{Monitor} implementation provided for
835 the Java \texttt{Object} class. This is also sometimes referred to as a barrier. We
837 This is just a bit of syntactic sugar, but, like its Java counterpart, clearly
853 class. A \texttt{Thread} is the actual schedulable object. The
854 \texttt{Runnable} is the logic to execute within the thread.
858 is that developers can easily subclass the Runnable class without pulling in
871 …about when \texttt{ThreadMain}, a C thread's entry-point function, will be called. Therefore, it is
874 well before that time. To ensure that the returned \texttt{Thread} object is not
888 to itself wrapped by the same \texttt{boost::shared\_ptr} envelope that is returned
897 object may need to know about the thread in which it is executing, and a Thread, obviously,
898 needs to know what \texttt{Runnable} object it is hosting. This interdependency is
899 further complicated because the lifecycle of each object is independent of the
915 implementing load metrics and thread pool size is very application
928 is to allows applications to sample \texttt{ThreadManager} load at regular
948 The Thrift compiler is implemented in C++ using standard \texttt{lex}/\texttt{yacc}
955 Code generation is done using two passes. The first pass looks only for
959 resolved, a second pass over all files is taken that inserts type definitions
960 into the parse tree and raises an error on any undefined types. The program is
975 A Thrift log file is split up into chunks of a specified size; logged messages
987 Thrift is used as the underlying protocol and transport layer for the Facebook Search service.
988 The multi-language code generation is well suited for search because it allows for application
990 to make calls to the search service using Thrift PHP libraries. There is also a large
991 variety of search stats, deployment and testing functionality that is built on top
992 of generated Python code. Additionally, the Thrift log file format is
997 The Thrift \texttt{TFileTransport} functionality is used for structured logging. Each
1012 software abstraction is far eclipsed by the gains in developer efficiency and
1018 The following are software systems similar to Thrift. Each is (very!) briefly
1039 Thrift is a successor to Pillar, a similar system developed