[jira] [Updated] (THRIFT-1221) Remove SimpleCallback.h
[ https://issues.apache.org/jira/browse/THRIFT-1221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diwaker Gupta updated THRIFT-1221: -- Attachment: THRIFT-1121.patch > Remove SimpleCallback.h > --- > > Key: THRIFT-1221 > URL: https://issues.apache.org/jira/browse/THRIFT-1221 > Project: Thrift > Issue Type: Improvement > Components: C++ - Library > Environment: Ubuntu 11.04 >Reporter: Diwaker Gupta >Priority: Trivial > Attachments: THRIFT-1121.patch > > > This file is not used anywhere in the current code base. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (THRIFT-1221) Remove SimpleCallback.h
Remove SimpleCallback.h --- Key: THRIFT-1221 URL: https://issues.apache.org/jira/browse/THRIFT-1221 Project: Thrift Issue Type: Improvement Components: C++ - Library Environment: Ubuntu 11.04 Reporter: Diwaker Gupta Priority: Trivial This file is not used anywhere in the current code base. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: why is there seemingly no support for "float" (32 bit values) type in thrift?
It's true, we don't have a 32 bit float. In practice, I don't think that most people have suffered too heavily from the omission, since floating point data isn't as common. I think that in practice it would be very hard to add a new fundamental datatype to Thrift because there are so many languages and protocols that would have to be updated accordingly. -Bryan On Mon, Jun 27, 2011 at 2:59 PM, Gautam Thaker wrote: > I am reading/running/modifying the tutorial as a way to understand > thrift. I noticed that thrift only seems to support a 64 bit float > value, and not a 32 bit float value. There are times when 32 bit values > would be a better choice. > > Is this hard to add? > > Gautam >
why is there seemingly no support for "float" (32 bit values) type in thrift?
I am reading/running/modifying the tutorial as a way to understand thrift. I noticed that thrift only seems to support a 64 bit float value, and not a 32 bit float value. There are times when 32 bit values would be a better choice. Is this hard to add? Gautam
Uptake libevent 2.0.x?
This might have been discussed on the list but the mailing list archives didn't turn up much. What do the devs think of uptaking libevent 2.0.x? * Several useful features (such as bufferevents) * Better windows support * Many distributions already support it (Debian) or will soon support it (Ubuntu, Fedora) Diwaker
[jira] [Commented] (THRIFT-1220) TProcessor::process never returns false
[
https://issues.apache.org/jira/browse/THRIFT-1220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13055757#comment-13055757
]
Hudson commented on THRIFT-1220:
Integrated in Thrift #180 (See [https://builds.apache.org/job/Thrift/180/])
Thrift-1220: TRpocessor::process never returns false
Client: c++
Patch: Diwaker Gupta
Fixes issue with return values always returning true from process method when
an exception or error occurs.
> TProcessor::process never returns false
> ---
>
> Key: THRIFT-1220
> URL: https://issues.apache.org/jira/browse/THRIFT-1220
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Compiler
>Affects Versions: 0.6
> Environment: Ubuntu 11.04, Thrift trunk.
>Reporter: Diwaker Gupta
>Assignee: Diwaker Gupta
>Priority: Minor
> Fix For: 0.7
>
> Attachments: THRIFT-1120.patch
>
>
> The signature of TProcessor::process is
> {noformat}
> virtual bool process(boost::shared_ptr in,
>boost::shared_ptr out,
>void* connectionContext) = 0;
> {noformat}
> Presumably, the return value is supposed to indicate success or failure.
> Unfortunately the generated C++ code _always_ returns true, even when there
> are errors. For instance, if an RPC call is received but no matching function
> exists, we return a TException in the response but the 'process' method still
> returns true.
> The attached patch makes the return values useful.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Erlang implementation of the JSON protocol
Hey, thanks for making the effort to contribute! The best next step would be to open a ticket in our JIRA and attach a patch. On Mon, Jun 27, 2011 at 11:55 AM, Peter Neumark wrote: > I have written a thrift json protocol implementation for erlang. > > My implementation of the protocol may be found here: > > https://github.com/postlock/thrift/blob/trunk/lib/erl/src/thrift_json_protocol.erl > > A modified version of the erlang thrift tutorial which uses my > implementation over HTTP to talk to the same server that the javascript > tutorial uses: > https://github.com/postlock/thrift/blob/trunk/tutorial/erl/json_client.erl > > Finally, it should be noted that the code depends on JSX: > https://github.com/talentdeficit/jsx > > I haven't had time to run a huge amount of tests on it yet, but the > tutorial > seems to work fine. > What are the steps needed to get this into the official thrift codebase? > > Peter >
[jira] [Commented] (THRIFT-1184) event_base memory freeing by class TNonblockingServer
[ https://issues.apache.org/jira/browse/THRIFT-1184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13055730#comment-13055730 ] Nevo Hed commented on THRIFT-1184: -- +1 I think the feature of running TNonBlocking on an existing event_base is an important one, if there are any users that run this in a scenario that is not run-forever then this would be a show-stopper for them > event_base memory freeing by class TNonblockingServer > - > > Key: THRIFT-1184 > URL: https://issues.apache.org/jira/browse/THRIFT-1184 > Project: Thrift > Issue Type: Bug > Components: C++ - Library >Reporter: Pavlin Radoslavov > Labels: libevent > Attachments: thrift1184_eventbase_free.patch > > > The TNonblockingServer::eventBase_ pointer is assigned > by method TNonblockingServer::registerEvents() > so the libevent events are added to the proper libevent event base. > Currently the TNonblockingServer destructor unconditionally > calls event_base_free(eventBase_) to free the eventBase_ memory. > In certain cases the libevent event base might be allocated and > deallocated by a third-party software that uses Thrift, so it is > not appropriate for the TNonblockingServer destructor to unconditionally > call event_base_free(eventBase_). > Please see attached patch for a possible solution: > add an optional bool argument to method TNonblockingServer::registerEvents(): > the value of that flag controls whether the TNonblockingServer destructor > should call event_base_free(eventBase_). > The argument is optional, and defaults to true (i.e, > event_base_free(eventBase_) > is called) for API (and behavior) backward compatibility. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Erlang implementation of the JSON protocol
I have written a thrift json protocol implementation for erlang. My implementation of the protocol may be found here: https://github.com/postlock/thrift/blob/trunk/lib/erl/src/thrift_json_protocol.erl A modified version of the erlang thrift tutorial which uses my implementation over HTTP to talk to the same server that the javascript tutorial uses: https://github.com/postlock/thrift/blob/trunk/tutorial/erl/json_client.erl Finally, it should be noted that the code depends on JSX: https://github.com/talentdeficit/jsx I haven't had time to run a huge amount of tests on it yet, but the tutorial seems to work fine. What are the steps needed to get this into the official thrift codebase? Peter
[jira] [Closed] (THRIFT-1220) TProcessor::process never returns false
[
https://issues.apache.org/jira/browse/THRIFT-1220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jake Farrell closed THRIFT-1220.
Resolution: Fixed
Fix Version/s: 0.7
Assignee: Diwaker Gupta
Thanks for the patch, committed to trunk
> TProcessor::process never returns false
> ---
>
> Key: THRIFT-1220
> URL: https://issues.apache.org/jira/browse/THRIFT-1220
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Compiler
>Affects Versions: 0.6
> Environment: Ubuntu 11.04, Thrift trunk.
>Reporter: Diwaker Gupta
>Assignee: Diwaker Gupta
>Priority: Minor
> Fix For: 0.7
>
> Attachments: THRIFT-1120.patch
>
>
> The signature of TProcessor::process is
> {noformat}
> virtual bool process(boost::shared_ptr in,
>boost::shared_ptr out,
>void* connectionContext) = 0;
> {noformat}
> Presumably, the return value is supposed to indicate success or failure.
> Unfortunately the generated C++ code _always_ returns true, even when there
> are errors. For instance, if an RPC call is received but no matching function
> exists, we return a TException in the response but the 'process' method still
> returns true.
> The attached patch makes the return values useful.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (THRIFT-1220) TProcessor::process never returns false
[
https://issues.apache.org/jira/browse/THRIFT-1220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Diwaker Gupta updated THRIFT-1220:
--
Attachment: THRIFT-1120.patch
> TProcessor::process never returns false
> ---
>
> Key: THRIFT-1220
> URL: https://issues.apache.org/jira/browse/THRIFT-1220
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Compiler
>Affects Versions: 0.6
> Environment: Ubuntu 11.04, Thrift trunk.
>Reporter: Diwaker Gupta
>Priority: Minor
> Attachments: THRIFT-1120.patch
>
>
> The signature of TProcessor::process is
> {noformat}
> virtual bool process(boost::shared_ptr in,
>boost::shared_ptr out,
>void* connectionContext) = 0;
> {noformat}
> Presumably, the return value is supposed to indicate success or failure.
> Unfortunately the generated C++ code _always_ returns true, even when there
> are errors. For instance, if an RPC call is received but no matching function
> exists, we return a TException in the response but the 'process' method still
> returns true.
> The attached patch makes the return values useful.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (THRIFT-1220) TProcessor::process never returns false
TProcessor::process never returns false
---
Key: THRIFT-1220
URL: https://issues.apache.org/jira/browse/THRIFT-1220
Project: Thrift
Issue Type: Bug
Components: C++ - Compiler
Affects Versions: 0.6
Environment: Ubuntu 11.04, Thrift trunk.
Reporter: Diwaker Gupta
Priority: Minor
The signature of TProcessor::process is
{noformat}
virtual bool process(boost::shared_ptr in,
boost::shared_ptr out,
void* connectionContext) = 0;
{noformat}
Presumably, the return value is supposed to indicate success or failure.
Unfortunately the generated C++ code _always_ returns true, even when there are
errors. For instance, if an RPC call is received but no matching function
exists, we return a TException in the response but the 'process' method still
returns true.
The attached patch makes the return values useful.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (THRIFT-1177) Update thrift to reflect changes in Go's networking libraries
[ https://issues.apache.org/jira/browse/THRIFT-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13055668#comment-13055668 ] Bryan Duxbury commented on THRIFT-1177: --- Just to be clear, it's the first patch that should be committed, correct? That's the one that works with stable Go interpreter? > Update thrift to reflect changes in Go's networking libraries > - > > Key: THRIFT-1177 > URL: https://issues.apache.org/jira/browse/THRIFT-1177 > Project: Thrift > Issue Type: Dependency upgrade > Components: Go - Compiler, Go - Library >Affects Versions: 0.7 >Reporter: Aalok Shah >Priority: Minor > Fix For: 0.7 > > Attachments: gopatch2-r2.diff, gopatch2.diff > > > Go updated its networking libraries requiring a change to both the thrift > code generator and the libraries. > Additionally, the Go generator did not support arguments/variables that were > Go keywords, this needs to be updated to work with Cassandra's thrift since > "range" is a Go keyword. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
