[jira] [Commented] (THRIFT-2252) Optimize the overhead of the tag message of the request
[
https://issues.apache.org/jira/browse/THRIFT-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13814621#comment-13814621
]
George Cao commented on THRIFT-2252:
[~jensg], I think the mapping between function name and it's ID may be stored
as meta data on both the client and server sides, then we can reduce the
network overhead. I am interested in the *more options* you mentioned above,
would you tell me more detail about them?
> Optimize the overhead of the tag message of the request
> ---
>
> Key: THRIFT-2252
> URL: https://issues.apache.org/jira/browse/THRIFT-2252
> Project: Thrift
> Issue Type: Improvement
>Reporter: George Cao
> Labels: optimization, payload, perfomance
>
> For now, every request the client sent consists of a tag message(TMessage)
> and the API arguments.
> This tag message includes the API name(method name), message type and a
> sequence ID.
> Compare to the API arguments which usually are some structure data like
> integers, the tag message will cause a lot of overhead because of the API
> name string.
> For example, assume we have an API like this in Java:
> {code}
> int getSomeEntityById(int id);
> {code}
> The the tag message will takes *len("getSomeEntityById") + 1 + 4 = 22* bytes
> and the API arguments only takes 4 bytes.
>
> Even worse if we support multiplexing, because we need append additional
> service name at the beginning of the API name.
> So shall we assign an ID to each API like struct's every property has an ID?
> Then we can avoid using the verbose string names.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (THRIFT-2252) Optimize the overhead of the tag message of the request
[
https://issues.apache.org/jira/browse/THRIFT-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13814617#comment-13814617
]
George Cao commented on THRIFT-2252:
[~ben.craig], generated processing code uses the function name also. So I think
we need more modifications.
> Optimize the overhead of the tag message of the request
> ---
>
> Key: THRIFT-2252
> URL: https://issues.apache.org/jira/browse/THRIFT-2252
> Project: Thrift
> Issue Type: Improvement
>Reporter: George Cao
> Labels: optimization, payload, perfomance
>
> For now, every request the client sent consists of a tag message(TMessage)
> and the API arguments.
> This tag message includes the API name(method name), message type and a
> sequence ID.
> Compare to the API arguments which usually are some structure data like
> integers, the tag message will cause a lot of overhead because of the API
> name string.
> For example, assume we have an API like this in Java:
> {code}
> int getSomeEntityById(int id);
> {code}
> The the tag message will takes *len("getSomeEntityById") + 1 + 4 = 22* bytes
> and the API arguments only takes 4 bytes.
>
> Even worse if we support multiplexing, because we need append additional
> service name at the beginning of the API name.
> So shall we assign an ID to each API like struct's every property has an ID?
> Then we can avoid using the verbose string names.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (THRIFT-2252) Optimize the overhead of the tag message of the request
[
https://issues.apache.org/jira/browse/THRIFT-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
George Cao updated THRIFT-2252:
---
Description:
For now, every request the client sent consists of a tag message(TMessage) and
the API arguments.
This tag message includes the API name(method name), message type and a
sequence ID.
Compare to the API arguments which usually are some structure data like
integers, the tag message will cause a lot of overhead because of the API name
string.
For example, assume we have an API like this in Java:
{code}
int getSomeEntityById(int id);
{code}
The the tag message will takes *len("getSomeEntityById") + 1 + 4 = 22* bytes
and the API arguments only takes 4 bytes.
Even worse if we support multiplexing, because we need append additional
service name at the beginning of the API name.
So shall we assign an ID to each API like struct's every property has an ID?
Then we can avoid using the verbose string names.
was:
For now, every request the client sent consists of a tag message(TMessage) and
the API arguments.
This tag message includes the API name(method name), message type and a
sequence ID.
Compare to the API arguments which usually are some structure data like
integers, the tag message will cause a lot of overhead because of the API name
string.
For example, assume we have an API like this in Java:
{code}
int getSomeEntityById(int id);
{code}
The the tag message will takes len("getSomeEntityById") + 1 + 4 = 22 bytes and
the API arguments only takes 4 bytes.
Even worse if we support multiplexing, because we need append additional
service name at the beginning of the API name.
So shall we assign an ID to each API like struct's every property has an ID?
Then we can avoid using the verbose string names.
> Optimize the overhead of the tag message of the request
> ---
>
> Key: THRIFT-2252
> URL: https://issues.apache.org/jira/browse/THRIFT-2252
> Project: Thrift
> Issue Type: Improvement
>Reporter: George Cao
> Labels: optimization, payload, perfomance
>
> For now, every request the client sent consists of a tag message(TMessage)
> and the API arguments.
> This tag message includes the API name(method name), message type and a
> sequence ID.
> Compare to the API arguments which usually are some structure data like
> integers, the tag message will cause a lot of overhead because of the API
> name string.
> For example, assume we have an API like this in Java:
> {code}
> int getSomeEntityById(int id);
> {code}
> The the tag message will takes *len("getSomeEntityById") + 1 + 4 = 22* bytes
> and the API arguments only takes 4 bytes.
>
> Even worse if we support multiplexing, because we need append additional
> service name at the beginning of the API name.
> So shall we assign an ID to each API like struct's every property has an ID?
> Then we can avoid using the verbose string names.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (THRIFT-2252) Optimize the overhead of the tag message of the request
[
https://issues.apache.org/jira/browse/THRIFT-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
George Cao updated THRIFT-2252:
---
Description:
For now, every request the client sent consists of a tag message(TMessage) and
the API arguments.
This tag message includes the API name(method name), message type and a
sequence ID.
Compare to the API arguments which usually are some structure data like
integers, the tag message will cause a lot of overhead because of the API name
string.
For example, assume we have an API like this in Java:
{code}
int getSomeEntityById(int id);
{code}
The the tag message will takes len("getSomeEntityById") + 1 + 4 = 22 bytes and
the API arguments only takes 4 bytes.
Even worse if we support multiplexing, because we need append additional
service name at the beginning of the API name.
So shall we assign an ID to each API like struct's every property has an ID?
Then we can avoid using the verbose string names.
was:
For now, every request the client sent consists of a tag message(TMessage) and
the API arguments.
This tag message includes the API name(method name), message type and a
sequence ID.
Compare to the API arguments which usually are some structure data like
integers, the tag message will cause a lot of overhead because of the API name
string.
For example, assume we have an API like this in Java:
int getSomeEntityById(int id);
The the tag message will takes len("getSomeEntityById") + 1 + 4 = 22 bytes and
the API arguments only takes 4 bytes.
Even worse if we support multiplexing, because we need append additional
service name at the beginning of the API name.
So shall we assign an ID to each API like struct's every property has an ID?
Then we can avoid using the verbose string names.
> Optimize the overhead of the tag message of the request
> ---
>
> Key: THRIFT-2252
> URL: https://issues.apache.org/jira/browse/THRIFT-2252
> Project: Thrift
> Issue Type: Improvement
>Reporter: George Cao
> Labels: optimization, payload, perfomance
>
> For now, every request the client sent consists of a tag message(TMessage)
> and the API arguments.
> This tag message includes the API name(method name), message type and a
> sequence ID.
> Compare to the API arguments which usually are some structure data like
> integers, the tag message will cause a lot of overhead because of the API
> name string.
> For example, assume we have an API like this in Java:
> {code}
> int getSomeEntityById(int id);
> {code}
> The the tag message will takes len("getSomeEntityById") + 1 + 4 = 22 bytes
> and the API arguments only takes 4 bytes.
>
> Even worse if we support multiplexing, because we need append additional
> service name at the beginning of the API name.
> So shall we assign an ID to each API like struct's every property has an ID?
> Then we can avoid using the verbose string names.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (THRIFT-2252) Optimize the overhead of the tag message of the request
[
https://issues.apache.org/jira/browse/THRIFT-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
George Cao updated THRIFT-2252:
---
Description:
For now, every request the client sent consists of a tag message(TMessage) and
the API arguments.
This tag message includes the API name(method name), message type and a
sequence ID.
Compare to the API arguments which usually are some structure data like
integers, the tag message will cause a lot of overhead because of the API name
string.
For example, assume we have an API like this in Java:
int getSomeEntityById(int id);
The the tag message will takes len("getSomeEntityById") + 1 + 4 = 22 bytes and
the API arguments only takes 4 bytes.
Even worse if we support multiplexing, because we need append additional
service name at the beginning of the API name.
So shall we assign an ID to each API like struct's every property has an ID?
Then we can avoid using the verbose string names.
was:
For now, every request the client sent consists of a tag message(TMessage) and
the API arguments.
This tag message includes the API name(method name), message type and a
sequence ID.
Compare to the API arguments which usually are some structure data like
integers, the tag message will cause a lot of overhead because of the API name
string.
For example, assume we have an API like this in Java:
int getSomeEntityById(int id);
The the tag message will takes len("getSomeEntityById") + 1 + 4 = 22 bytes and
the API arguments only takes 4 bytes.
Even worse if we support multiplexing, because we need append additional
service name at the beginning of the API name.
So shall we assign an ID to each API like struct's every property has an ID?
Then we can avoid using the verbose string names.
> Optimize the overhead of the tag message of the request
> ---
>
> Key: THRIFT-2252
> URL: https://issues.apache.org/jira/browse/THRIFT-2252
> Project: Thrift
> Issue Type: Improvement
>Reporter: George Cao
> Labels: optimization, payload, perfomance
>
> For now, every request the client sent consists of a tag message(TMessage)
> and the API arguments.
> This tag message includes the API name(method name), message type and a
> sequence ID.
> Compare to the API arguments which usually are some structure data like
> integers, the tag message will cause a lot of overhead because of the API
> name string.
> For example, assume we have an API like this in Java:
>
> int getSomeEntityById(int id);
>
> The the tag message will takes len("getSomeEntityById") + 1 + 4 = 22 bytes
> and the API arguments only takes 4 bytes.
>
> Even worse if we support multiplexing, because we need append additional
> service name at the beginning of the API name.
> So shall we assign an ID to each API like struct's every property has an ID?
> Then we can avoid using the verbose string names.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (THRIFT-2252) Optimize the overhead of the tag message of the request
George Cao created THRIFT-2252:
--
Summary: Optimize the overhead of the tag message of the request
Key: THRIFT-2252
URL: https://issues.apache.org/jira/browse/THRIFT-2252
Project: Thrift
Issue Type: Improvement
Reporter: George Cao
For now, every request the client sent consists of a tag message(TMessage) and
the API arguments.
This tag message includes the API name(method name), message type and a
sequence ID.
Compare to the API arguments which usually are some structure data like
integers, the tag message will cause a lot of overhead because of the API name
string.
For example, assume we have an API like this in Java:
int getSomeEntityById(int id);
The the tag message will takes len("getSomeEntityById") + 1 + 4 = 22 bytes and
the API arguments only takes 4 bytes.
Even worse if we support multiplexing, because we need append additional
service name at the beginning of the API name.
So shall we assign an ID to each API like struct's every property has an ID?
Then we can avoid using the verbose string names.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (THRIFT-1708) Add event handlers for processor events
[ https://issues.apache.org/jira/browse/THRIFT-1708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13609963#comment-13609963 ] George Cao commented on THRIFT-1708: Is this patch accepted or rejected? Any progress? > Add event handlers for processor events > --- > > Key: THRIFT-1708 > URL: https://issues.apache.org/jira/browse/THRIFT-1708 > Project: Thrift > Issue Type: New Feature > Components: Java - Library >Affects Versions: 0.9 > Environment: all >Reporter: Andrew Cox >Assignee: Andrew Cox >Priority: Minor > Fix For: 1.0 > > Attachments: thrift-1708-processor-event-handlers.patch > > > Integrates some code we've been using (here at facebook) to add event > handlers that can handle processor events with the server event handlers in > apache thrift. > Processor events include: preRead (before reading arguments), postRead (after > reading arguments), preWrite (before writing results), postWrite (after > writing results), and processorError (when a non-IDL exception is thrown as a > result of an error handling the request). The processor handler is given the > method name and input and output protocol that will be used to process the > request, and can inspect arguments on postRead, and results on pre/postWrite > events. > This change also enables event handlers for non-blocking servers. > Some unit tests are included to exercise the new processor event handlers, > and demonstrate how they can connect with server event handlers. > It also fixes a minor bug I found while testing, where FrameBuffers on > non-blocking servers could have been close()'d more than once. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
