[jira] [Updated] (THRIFT-1845) Fix compiler warning caused by implicit string conversion with Xcode 4.6
[
https://issues.apache.org/jira/browse/THRIFT-1845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Diwaker Gupta updated THRIFT-1845:
--
Assignee: Jake Farrell
> Fix compiler warning caused by implicit string conversion with Xcode 4.6
>
>
> Key: THRIFT-1845
> URL: https://issues.apache.org/jira/browse/THRIFT-1845
> Project: Thrift
> Issue Type: Bug
> Components: C++ - Library
>Affects Versions: 0.9
> Environment: Building w/ clang as shipped with Xcode 4.6
>Reporter: Nate Rosenblum
>Assignee: Jake Farrell
> Fix For: 0.9
>
> Attachments: 0001-Don-t-rely-on-implicit-string-conversion.patch
>
>
> Clang doesn't do the implicit char[] -> std::string conversion before
> evaluating the + operator in the following statement (and even if it did, it
> would complain that there is no string::operator+ defined for a non-character
> integral type.
> {code}
> int8_t type;
> //...
> throw TException("don't know what type: " + type);
> {code}
--
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
[jira] [Commented] (THRIFT-1536) Maven thrift plugin
[ https://issues.apache.org/jira/browse/THRIFT-1536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13564526#comment-13564526 ] Diwaker Gupta commented on THRIFT-1536: --- [~bterm] any update on the availability of the Maven Thrift plugin in Maven Central? > Maven thrift plugin > --- > > Key: THRIFT-1536 > URL: https://issues.apache.org/jira/browse/THRIFT-1536 > Project: Thrift > Issue Type: New Feature >Reporter: Jake Farrell >Assignee: Jake Farrell > Attachments: maven-thrift-plugin.zip > > > Working with David Trott to bring the Maven thrift Plugin he has written into > the code base and deploy to maven central as part of the release process -- 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
[jira] [Updated] (THRIFT-1838) Can't build compiler on OS X because of missing thrifty.h
[
https://issues.apache.org/jira/browse/THRIFT-1838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Diwaker Gupta updated THRIFT-1838:
--
Attachment: THRIFT-1838.patch
I've only tested this on OS X, so its likely that this breaks the build on
other platforms. I'm happy to make the required changes but I won't be able to
test all platforms myself.
Also available at https://github.com/maginatics/thrift/tree/feature/THRIFT-1838
> Can't build compiler on OS X because of missing thrifty.h
> -
>
> Key: THRIFT-1838
> URL: https://issues.apache.org/jira/browse/THRIFT-1838
> Project: Thrift
> Issue Type: Bug
> Components: Compiler (General)
>Affects Versions: 0.9
> Environment: OS X 10.8.2
> Thrift trunk
> bison (GNU Bison) 2.3
> flex 2.5.35 Apple(flex-31)
> Note that I'm using the bison/flex that ship with OS X.
>Reporter: Diwaker Gupta
>Assignee: Jake Farrell
> Attachments: THRIFT-1838.patch
>
>
> With a clean checkout, run boostrap -> configure and try to build the
> compiler. Fails with:
> {noformat}
> /bin/sh ../../ylwrap `test -f 'src/thrifty.yy' || echo
> './'`src/thrifty.yy y.tab.c thrifty.cc y.tab.h `echo thrifty.cc | sed -e
> s/cc$/hh/ -e s/cpp$/hpp/ -e s/cxx$/hxx/ -e s
> /c++$/h++/ -e s/c$/h/` y.output thrifty.output -- bison -y -d updating
> thrifty.hhg++ -DHAVE_CONFIG_H -I. -I../.. -I./src -Wall -Wno-sign-compare
> -Wno-unused -g -O2 -MT libparse_a-thrifty.o -MD -MP -MF
> .deps/libparse_a-thrifty.Tpo -c -o libparse_a-thrifty.o `test -f 'thrifty.cc'
> || echo './'`thrifty.cc
> mv -f .deps/libparse_a-thrifty.Tpo .deps/libparse_a-thrifty.Po\ \
>/bin/sh ../../ylwrap `test -f 'src/thriftl.ll' || echo './'`src/thriftl.ll
> lex.yy.c thriftl.cc -- flex
> g++ -DHAVE_CONFIG_H -I. -I../.. -I./src -Wall -Wno-sign-compare -Wno-unused
> -g -O2 -MT libparse_a-thriftl.o -MD -MP -MF .deps/libparse_a-thriftl.Tpo -c
> -o libparse_a-thriftl.o `t
> est -f 'thriftl.cc' || echo './'`thriftl.cc
> src/thriftl.ll:51:21: error: thrifty.h: No such file or directory
> {noformat}
--
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
[jira] [Created] (THRIFT-1838) Can't build compiler on OS X because of missing thrifty.h
Diwaker Gupta created THRIFT-1838:
-
Summary: Can't build compiler on OS X because of missing thrifty.h
Key: THRIFT-1838
URL: https://issues.apache.org/jira/browse/THRIFT-1838
Project: Thrift
Issue Type: Bug
Components: Compiler (General)
Affects Versions: 0.9
Environment: OS X 10.8.2
Thrift trunk
bison (GNU Bison) 2.3
flex 2.5.35 Apple(flex-31)
Note that I'm using the bison/flex that ship with OS X.
Reporter: Diwaker Gupta
Assignee: Jake Farrell
With a clean checkout, run boostrap -> configure and try to build the compiler.
Fails with:
{noformat}
/bin/sh ../../ylwrap `test -f 'src/thrifty.yy' || echo
'./'`src/thrifty.yy y.tab.c thrifty.cc y.tab.h `echo thrifty.cc | sed -e
s/cc$/hh/ -e s/cpp$/hpp/ -e s/cxx$/hxx/ -e s
/c++$/h++/ -e s/c$/h/` y.output thrifty.output -- bison -y -d updating
thrifty.hhg++ -DHAVE_CONFIG_H -I. -I../.. -I./src -Wall -Wno-sign-compare
-Wno-unused -g -O2 -MT libparse_a-thrifty.o -MD -MP -MF
.deps/libparse_a-thrifty.Tpo -c -o libparse_a-thrifty.o `test -f 'thrifty.cc'
|| echo './'`thrifty.cc
mv -f .deps/libparse_a-thrifty.Tpo .deps/libparse_a-thrifty.Po\ \
/bin/sh ../../ylwrap `test -f 'src/thriftl.ll' || echo './'`src/thriftl.ll
lex.yy.c thriftl.cc -- flex
g++ -DHAVE_CONFIG_H -I. -I../.. -I./src -Wall -Wno-sign-compare -Wno-unused
-g -O2 -MT libparse_a-thriftl.o -MD -MP -MF .deps/libparse_a-thriftl.Tpo -c -o
libparse_a-thriftl.o `t
est -f 'thriftl.cc' || echo './'`thriftl.cc
src/thriftl.ll:51:21: error: thrifty.h: No such file or directory
{noformat}
--
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
[jira] [Updated] (THRIFT-1805) Thrift should not swallow ALL exceptions
[ https://issues.apache.org/jira/browse/THRIFT-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diwaker Gupta updated THRIFT-1805: -- Attachment: THRIFT-1805.patch Also available at https://github.com/maginatics/thrift/tree/feature/THRIFT-1805 > Thrift should not swallow ALL exceptions > > > Key: THRIFT-1805 > URL: https://issues.apache.org/jira/browse/THRIFT-1805 > Project: Thrift > Issue Type: Bug > Components: Java - Compiler, Java - Library >Affects Versions: 0.9 >Reporter: Diwaker Gupta >Assignee: Jake Farrell > Attachments: THRIFT-1805.patch > > > In Thrift 0.8.0, Thrift generated Java code did not swallow application > exceptions. As a result of THRIFT-1658, this behavior changed in 0.9.0 and > now the generated code swallows ALL application exceptions (via > ProcessFunction). Apparently this was the behavior in Thrift 0.6.0 and while > I see the rationale, it is breaking our applications. > Our code relies on the fact that exceptions can propagate outside of Thrift > for certain things (e.g., to aggressively drop connections for clients that > send invalid/malformed requests). ProcessFunction makes it near impossible to > do this -- not only does it swallow the exception, it also loses all > information about the original exception and just writes out a generic > TApplicationException. > IMO ProcessFunction should only catch TException. If the application code > wants to use other exceptions for some reason (in particular, Errors and > RuntimeExceptions), Thrift shouldn't prevent that. -- 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
[jira] [Commented] (THRIFT-1805) Thrift should not swallow ALL exceptions
[
https://issues.apache.org/jira/browse/THRIFT-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13559155#comment-13559155
]
Diwaker Gupta commented on THRIFT-1805:
---
[~roger.meier], I was able to run the Java unit tests successfully without any
problems. I don't see why my suggested change should have any impact on
ServerTestBase.testException. I'm now trying to run the integration test but
they have other issues on OS X (no {{timeout}} command, for instance) because
of which I'm unable to verify.
> Thrift should not swallow ALL exceptions
>
>
> Key: THRIFT-1805
> URL: https://issues.apache.org/jira/browse/THRIFT-1805
> Project: Thrift
> Issue Type: Bug
> Components: Java - Compiler, Java - Library
>Affects Versions: 0.9
>Reporter: Diwaker Gupta
>Assignee: Jake Farrell
>
> In Thrift 0.8.0, Thrift generated Java code did not swallow application
> exceptions. As a result of THRIFT-1658, this behavior changed in 0.9.0 and
> now the generated code swallows ALL application exceptions (via
> ProcessFunction). Apparently this was the behavior in Thrift 0.6.0 and while
> I see the rationale, it is breaking our applications.
> Our code relies on the fact that exceptions can propagate outside of Thrift
> for certain things (e.g., to aggressively drop connections for clients that
> send invalid/malformed requests). ProcessFunction makes it near impossible to
> do this -- not only does it swallow the exception, it also loses all
> information about the original exception and just writes out a generic
> TApplicationException.
> IMO ProcessFunction should only catch TException. If the application code
> wants to use other exceptions for some reason (in particular, Errors and
> RuntimeExceptions), Thrift shouldn't prevent that.
--
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
[jira] [Created] (THRIFT-1805) Thrift should not swallow ALL exceptions
Diwaker Gupta created THRIFT-1805: - Summary: Thrift should not swallow ALL exceptions Key: THRIFT-1805 URL: https://issues.apache.org/jira/browse/THRIFT-1805 Project: Thrift Issue Type: Bug Components: Java - Compiler, Java - Library Affects Versions: 0.9 Reporter: Diwaker Gupta Assignee: Jake Farrell In Thrift 0.8.0, Thrift generated Java code did not swallow application exceptions. As a result of THRIFT-1658, this behavior changed in 0.9.0 and now the generated code swallows ALL application exceptions (via ProcessFunction). Apparently this was the behavior in Thrift 0.6.0 and while I see the rationale, it is breaking our applications. Our code relies on the fact that exceptions can propagate outside of Thrift for certain things (e.g., to aggressively drop connections for clients that send invalid/malformed requests). ProcessFunction makes it near impossible to do this -- not only does it swallow the exception, it also loses all information about the original exception and just writes out a generic TApplicationException. IMO ProcessFunction should only catch TException. If the application code wants to use other exceptions for some reason (in particular, Errors and RuntimeExceptions), Thrift shouldn't prevent that. -- 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
[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=13538481#comment-13538481 ] Diwaker Gupta commented on THRIFT-1708: --- [~bterm], can we break this up into 3 separate patches for C++, Java and Python? I'd love to see this for Java asap and we needn't be blocked on support in other languages right? > 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
[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=13476564#comment-13476564 ] Diwaker Gupta commented on THRIFT-1708: --- I'd love to see this in the next 0.9.x release! [~andrewcox79] consider splitting the patch in two: one that adds TServerEventHandler support to the non-blocking servers, and then add ProcessorEventHandler support in a subsequent patch. > 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
[jira] [Created] (THRIFT-1718) Incorrect check in TFileTransportTest
Diwaker Gupta created THRIFT-1718:
-
Summary: Incorrect check in TFileTransportTest
Key: THRIFT-1718
URL: https://issues.apache.org/jira/browse/THRIFT-1718
Project: Thrift
Issue Type: Test
Components: C++ - Library
Affects Versions: 0.8
Reporter: Diwaker Gupta
Assignee: Jake Farrell
Priority: Minor
Fix For: 0.9
Attachments: THRIFT-1718.patch
TFileTransport:282, comment says:
" // Make sure TFileTransport called fsync at least once"
However, the test checks for greater than, resulting in failures.
This diff brings the check in line with the comment and fixes the failing tests:
{code}
--- lib/cpp/test/TFileTransportTest.cpp
+++ lib/cpp/test/TFileTransportTest.cpp
@@ -278,7 +278,7 @@ void test_flush_max_us_impl(uint32_t flush_us, uint32_t
write_us,
const FsyncLog::CallList* calls = log.getCalls();
// We added 1 fsync call above.
// Make sure TFileTransport called fsync at least once
- BOOST_CHECK_GT(calls->size(),
+ BOOST_CHECK_GE(calls->size(),
static_cast(1));
const struct timeval* prev_time = NULL;
{code}
--
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
[jira] [Updated] (THRIFT-1718) Incorrect check in TFileTransportTest
[
https://issues.apache.org/jira/browse/THRIFT-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Diwaker Gupta updated THRIFT-1718:
--
Attachment: THRIFT-1718.patch
> Incorrect check in TFileTransportTest
> -
>
> Key: THRIFT-1718
> URL: https://issues.apache.org/jira/browse/THRIFT-1718
> Project: Thrift
> Issue Type: Test
> Components: C++ - Library
>Affects Versions: 0.8
>Reporter: Diwaker Gupta
>Assignee: Jake Farrell
>Priority: Minor
> Fix For: 0.9
>
> Attachments: THRIFT-1718.patch
>
>
> TFileTransport:282, comment says:
> " // Make sure TFileTransport called fsync at least once"
> However, the test checks for greater than, resulting in failures.
> This diff brings the check in line with the comment and fixes the failing
> tests:
> {code}
> --- lib/cpp/test/TFileTransportTest.cpp
> +++ lib/cpp/test/TFileTransportTest.cpp
> @@ -278,7 +278,7 @@ void test_flush_max_us_impl(uint32_t flush_us, uint32_t
> write_us,
>const FsyncLog::CallList* calls = log.getCalls();
>// We added 1 fsync call above.
>// Make sure TFileTransport called fsync at least once
> - BOOST_CHECK_GT(calls->size(),
> + BOOST_CHECK_GE(calls->size(),
> static_cast(1));
>
>const struct timeval* prev_time = NULL;
> {code}
--
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
[jira] [Commented] (THRIFT-1023) Thrift encoding (UTF-8) issue with Ruby 1.9.2
[
https://issues.apache.org/jira/browse/THRIFT-1023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13464172#comment-13464172
]
Diwaker Gupta commented on THRIFT-1023:
---
[~nbeyer] can you attach the patch with tests included -- those of us who have
newer rspec locally can at least try it. FWIW, 'make check' works fine for me
using v4 on OS X Mountain Lion with Ruby 1.9.3
> Thrift encoding (UTF-8) issue with Ruby 1.9.2
> --
>
> Key: THRIFT-1023
> URL: https://issues.apache.org/jira/browse/THRIFT-1023
> Project: Thrift
> Issue Type: Bug
> Components: Ruby - Library
>Affects Versions: 0.5
> Environment: OSX, Ruby 1.9.2, Thrift Gem version 0.5.0
>Reporter: Vincent Peres
>Assignee: Jake Farrell
> Fix For: 0.9
>
> Attachments: THRIFT-1023-build-ruby19.patch,
> THRIFT-1023-refactor-transport-protocol-for-ruby19.patch,
> THRIFT-1023-refactor-transport-protocol-for-ruby19-v2.patch,
> THRIFT-1023-refactor-transport-protocol-for-ruby19-v3.patch,
> THRIFT-1023-refactor-transport-protocol-for-ruby19-v4.patch,
> thrift-1023-utf8-encoding-issue.path
>
>
> I came up with an encoding issue coming from the Thrift library, and
> especially the BufferedTransport class.
> I've decided to write down few tests to give you a concrete example :
> # encoding: utf-8
> require 'spec_helper'
> describe "encoding" do
> before do
>transport =
> Thrift::BufferedTransport.new(Thrift::Socket.new(MR_CONFIG['host'], 9090))
>protocol = Thrift::BinaryProtocol.new(transport)
>@client = Apache::Hadoop::Hbase::Thrift::Hbase::Client.new(protocol)
>transport.open()
>@table_name = "encoding_test"
>@column_family = "info:"
> end
> it "should create a new table" do
>column = Apache::Hadoop::Hbase::Thrift::ColumnDescriptor.new{|c| c.name=
> @column_family}
>@client.createTable(@table_name, [column]).should be_nil
> end
> it "should save standard caracteres" do
>m= Apache::Hadoop::Hbase::Thrift::Mutation.new
>m.column = "info:first_name"
>m.value = "Vincent"
>m.value.encoding.should == Encoding::UTF_8
>@client.mutateRow(@table_name, "ID1", [m]).should be_nil
> end
> it "should save UTF8 caracteres" do
>m= Apache::Hadoop::Hbase::Thrift::Mutation.new
>m.column = "info:first_name"
>m.value = "Thorbjørn"
>m.value.encoding.should == Encoding::UTF_8
>@client.mutateRow(@table_name, "ID1", [m]).should be_nil
> end
> it "should destroy the table" do
>@client.disableTable(@table_name).should be_nil
>@client.deleteTable(@table_name).should be_nil
> end
> end
> It fails when it tries to save the UTF8 string including the caractere 'ø'.
> Here is the output :
> 1) encoding should save UTF8 caracteres
> Failure/Error: @client.mutateRow(@table_name, "ID1", [m]).should be_nil
> incompatible character encodings: ASCII-8BIT and UTF-8
>
> #/Users/vincentp/.rvm/gems/ruby-1.9.2-p0/gems/thrift-0.5.0/lib/thrift/transport/buffered_transport.rb:59:in
> `write'
>
> #/Users/vincentp/.rvm/gems/ruby-1.9.2-p0/gems/thrift-0.5.0/lib/thrift/protocol/binary_protocol.rb:107:in
> `write_string'
>
> #/Users/vincentp/.rvm/gems/ruby-1.9.2-p0/gems/thrift-0.5.0/lib/thrift/client.rb:35:in
> `write'
>
> #/Users/vincentp/.rvm/gems/ruby-1.9.2-p0/gems/thrift-0.5.0/lib/thrift/client.rb:35:in
> `send_message'
> # ./lib/thrift/hbase.rb:289:in `send_mutateRow'
> # ./lib/thrift/hbase.rb:284:in `mutateRow'
> # ./spec/thrift/cases/encoding_spec.rb:37:in `block (2 levels) in (required)>'
> Let me know if you need any other details, thank you !
--
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
[jira] [Created] (THRIFT-1676) Allow specifying IP/hostname in TServer::serve
Diwaker Gupta created THRIFT-1676:
-
Summary: Allow specifying IP/hostname in TServer::serve
Key: THRIFT-1676
URL: https://issues.apache.org/jira/browse/THRIFT-1676
Project: Thrift
Issue Type: Improvement
Components: C++ - Library
Affects Versions: 0.8
Environment: Mac OS X. Thrift 0.8.0.
Reporter: Diwaker Gupta
Assignee: Jake Farrell
Thrift doesn't allow users to specify which IP/hostname to use for bind. As a
result, a Thrift server usually ends up listening on ALL interfaces on a
machine (bind uses INADDR_ANY). This is clearly undesirable in many cases where
we may want to restrict connectivity to localhost or to within a particular
subnet or targeted towards a specific host or IP.
Here's a example of what TNonblockingServer does:
{code}
// Wildcard address
error = getaddrinfo(NULL, port, &hints, &res0);
if (error) {
throw TException("TNonblockingServer::serve() getaddrinfo " +
string(gai_strerror(error)));
}
// Pick the ipv6 address first since ipv4 addresses can be mapped
// into ipv6 space.
for (res = res0; res; res = res->ai_next) {
if (res->ai_family == AF_INET6 || res->ai_next == NULL)
break;
}
{code}
As can be seen, the above code fragment provides NULL as the first param to
getaddrinfo and always specifies AI_PASSIVE. This results in the behavior I
described above.
A better approach IMO is to provide the following interface instead:
{code}
TServer::serve(const char* hostOrIp, int port)
{code}
This is consistent with what other modern server frameworks do (node.js, netty
etc.)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (THRIFT-1306) Fix stale documentation
[ https://issues.apache.org/jira/browse/THRIFT-1306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diwaker Gupta updated THRIFT-1306: -- Attachment: THRIFT-1306.patch > Fix stale documentation > --- > > Key: THRIFT-1306 > URL: https://issues.apache.org/jira/browse/THRIFT-1306 > Project: Thrift > Issue Type: Improvement > Components: C++ - Library >Affects Versions: 0.7 >Reporter: Diwaker Gupta >Priority: Trivial > Attachments: THRIFT-1306.patch > > > Fix documentation to match API change. Also format to 80 chars. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (THRIFT-1306) Fix stale documentation
Fix stale documentation --- Key: THRIFT-1306 URL: https://issues.apache.org/jira/browse/THRIFT-1306 Project: Thrift Issue Type: Improvement Components: C++ - Library Affects Versions: 0.7 Reporter: Diwaker Gupta Priority: Trivial Fix documentation to match API change. Also format to 80 chars. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (THRIFT-1243) TAsyncChannel callbacks
[ https://issues.apache.org/jira/browse/THRIFT-1243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13093043#comment-13093043 ] Diwaker Gupta commented on THRIFT-1243: --- Saw this a bit late but I'm concerned about this change. With this change, there is no way for implementors of sendMessage/recvMessage to signal to the callers that something unexpected happened or any other error conditions. Just because the current implementation ignores the return values doesn't mean they're not useful. Is the recommendation now to throw a TException instead? > TAsyncChannel callbacks > --- > > Key: THRIFT-1243 > URL: https://issues.apache.org/jira/browse/THRIFT-1243 > Project: Thrift > Issue Type: Improvement > Components: C++ - Library >Affects Versions: 0.7 > Environment: Visual C++ 2010 >Reporter: alexandre parenteau >Assignee: alexandre parenteau >Priority: Minor > Labels: patch > Fix For: 0.8 > > Attachments: THRIFT-1243.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > [Context: This patch is part of a larger patch to use thriftnb on > Windows/VisualC++. See > https://github.com/aubonbeurre/thrift/blob/alex-0.7.0/README.non.blocking.Windows > for more details.] > When compiling using Visual C++ 2010, the compiler chokes on casting some > callbacks bool(*)() to void(*)(). > Although probably valid and supported by gcc, this is further complicated by > the fact those casting seem unnecessary: for each of the callbacks returning > bool in TAsyncChannel.h: > 1. the returned value is never checked > 2. they always return true > Attached is a trivial patch based on 0.7.0, tested on Ubuntu 11.04 and Visual > C++ 2010. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (THRIFT-1296) SSL detection is broken
[
https://issues.apache.org/jira/browse/THRIFT-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13092989#comment-13092989
]
Diwaker Gupta commented on THRIFT-1296:
---
My AC-foo is fairly limited, but IIUC you need to include '-lcrypto' in the
last (5th) parameter to AC_CHECK_LIB(ssl...). The reason being that just to
link against libssl to check for SSL_ctrl, you need to also link against
libcrypto (at least on my platform); otherwise GCC fails complaining about
missing symbols. Otherwise the patch looks great!
> SSL detection is broken
> ---
>
> Key: THRIFT-1296
> URL: https://issues.apache.org/jira/browse/THRIFT-1296
> Project: Thrift
> Issue Type: Bug
> Components: Build Process
>Affects Versions: 0.7
> Environment: Ubuntu 10.04
> Building Thrift against a custom toolchain (not using system
> packages/libraries)
>Reporter: Diwaker Gupta
>Assignee: Jake Farrell
> Attachments: THRIFT-1296.patch, thrift-1296.patch
>
>
> When using shared libraries, libssl has dependencies on libcrypto. The
> current autoconf macro for checking SSL doesn't do the job:
> {noformat}
> configure:23665: checking for SSL_ctrl in -lssl
> configure:23690: x86_64-unknown-linux-gnu-g++ -o conftest -O2 -Wall -pipe
> -L -I -O2 -Wall -pipe conftest.cpp -lssl -lrt -lpthread >&5
> x86_64-unknown-linux-gnu/bin/ld: warning: libcrypto.so.1.0.0, needed by
> /usr/lib/libssl.so, not found (try using -rpath or -rpath-link)
> {noformat}
> The following patch fixes this problem:
> {noformat}
> +--- configure.ac
> configure.ac
> +@@ -312,7 +312,7 @@ dnl of the POSIX Real-Time Extensions. This seems
> necessary on Linux,
> + dnl and we haven't yet found a system where this is a problem.
> + AC_CHECK_LIB(rt, clock_gettime)
> + AC_CHECK_LIB(socket, setsockopt)
> +-AC_CHECK_LIB(ssl, SSL_ctrl)
> ++AC_CHECK_LIB(ssl, SSL_ctrl,[LIBS="-lssl -lcrypto $LIBS"],,-lcrypto)
> +
> + AC_TYPE_INT16_T
> + AC_TYPE_INT32_T
> {noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (THRIFT-1299) If SSL is available, 'thrift' binary links against it
[ https://issues.apache.org/jira/browse/THRIFT-1299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13092985#comment-13092985 ] Diwaker Gupta commented on THRIFT-1299: --- Looks good to me! > If SSL is available, 'thrift' binary links against it > - > > Key: THRIFT-1299 > URL: https://issues.apache.org/jira/browse/THRIFT-1299 > Project: Thrift > Issue Type: Bug > Components: Build Process, C++ - Compiler, C++ - Library >Affects Versions: 0.7 >Reporter: Diwaker Gupta >Assignee: Jake Farrell >Priority: Minor > Attachments: thrift-1299.patch > > > Inspection of compiler/cpp/Makefile and lib/cpp/Makefile reveals that for > building both the thrift compiler as well as the C++ libraries, the same set > of libraries (in the variable LIBS) are used. When OpenSSL is available, this > has the unintended consequence that the thrift compiler links libssl (and > potentially libcrypto), even though it doesn't need to. In theory there is no > harm in linking against additional shared libraries but it can be an issue in > practice. Specifically, if OpenSSL etc are installed in a custom location > (such as when building a custom toolchain), the thrift binary will fail to > run unless LD_LIBRARY_PATH is set every time thrift needs to run. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (THRIFT-1300) Test failures with parallel builds (make -j)
Test failures with parallel builds (make -j)
Key: THRIFT-1300
URL: https://issues.apache.org/jira/browse/THRIFT-1300
Project: Thrift
Issue Type: Bug
Components: Test Suite
Affects Versions: 0.7
Reporter: Diwaker Gupta
Simply running 'make' works fine -- builds the library, builds the tests etc.
Running 'make -j 12' fails when building the tests. Note that this worked fine
with 0.6.0.
{noformat}
../../compiler/cpp/thrift --gen cpp:templates,cob_style -r
../../test/ThriftTest.thrift
if /bin/bash ../../libtool --tag=CXX --mode=compile
x86_64-unknown-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I../..
-I../../lib/cpp/src -Igen-cpp -O2 -Wall -pipe -L -I -Wall -O2
-Wall -pipe -MT ThriftTest_types.lo -MD -MP -MF ".deps/ThriftTest_types.Tpo" -c
-o ThriftTest_types.lo `test -f 'gen-cpp/ThriftTest_types.cpp' || echo
'./'`gen-cpp/ThriftTest_types.cpp; \
then mv -f ".deps/ThriftTest_types.Tpo" ".deps/ThriftTest_types.Plo";
else rm -f ".deps/ThriftTest_types.Tpo"; exit 1; fi
../../compiler/cpp/thrift --gen cpp ../../test/StressTest.thrift
../../compiler/cpp/thrift --gen cpp ../../test/StressTest.thrift
make[4]: *** No rule to make target `gen-cpp/Service.cpp', needed by
`Service.lo'. Stop.
make[4]: *** Waiting for unfinished jobs
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (THRIFT-1299) If SSL is available, 'thrift' binary links against it
If SSL is available, 'thrift' binary links against it - Key: THRIFT-1299 URL: https://issues.apache.org/jira/browse/THRIFT-1299 Project: Thrift Issue Type: Bug Components: Build Process, C++ - Compiler, C++ - Library Affects Versions: 0.7 Reporter: Diwaker Gupta Priority: Minor Inspection of compiler/cpp/Makefile and lib/cpp/Makefile reveals that for building both the thrift compiler as well as the C++ libraries, the same set of libraries (in the variable LIBS) are used. When OpenSSL is available, this has the unintended consequence that the thrift compiler links libssl (and potentially libcrypto), even though it doesn't need to. In theory there is no harm in linking against additional shared libraries but it can be an issue in practice. Specifically, if OpenSSL etc are installed in a custom location (such as when building a custom toolchain), the thrift binary will fail to run unless LD_LIBRARY_PATH is set every time thrift needs to run. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (THRIFT-1296) SSL detection is broken
[
https://issues.apache.org/jira/browse/THRIFT-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Diwaker Gupta updated THRIFT-1296:
--
Attachment: THRIFT-1296.patch
I've only tested on Ubuntu 10.04. Some more testing on other platforms is
definitely needed.
> SSL detection is broken
> ---
>
> Key: THRIFT-1296
> URL: https://issues.apache.org/jira/browse/THRIFT-1296
> Project: Thrift
> Issue Type: Bug
> Components: Build Process
>Affects Versions: 0.7
> Environment: Ubuntu 10.04
> Building Thrift against a custom toolchain (not using system
> packages/libraries)
>Reporter: Diwaker Gupta
> Attachments: THRIFT-1296.patch
>
>
> When using shared libraries, libssl has dependencies on libcrypto. The
> current autoconf macro for checking SSL doesn't do the job:
> {noformat}
> configure:23665: checking for SSL_ctrl in -lssl
> configure:23690: x86_64-unknown-linux-gnu-g++ -o conftest -O2 -Wall -pipe
> -L -I -O2 -Wall -pipe conftest.cpp -lssl -lrt -lpthread >&5
> x86_64-unknown-linux-gnu/bin/ld: warning: libcrypto.so.1.0.0, needed by
> /usr/lib/libssl.so, not found (try using -rpath or -rpath-link)
> {noformat}
> The following patch fixes this problem:
> {noformat}
> +--- configure.ac
> configure.ac
> +@@ -312,7 +312,7 @@ dnl of the POSIX Real-Time Extensions. This seems
> necessary on Linux,
> + dnl and we haven't yet found a system where this is a problem.
> + AC_CHECK_LIB(rt, clock_gettime)
> + AC_CHECK_LIB(socket, setsockopt)
> +-AC_CHECK_LIB(ssl, SSL_ctrl)
> ++AC_CHECK_LIB(ssl, SSL_ctrl,[LIBS="-lssl -lcrypto $LIBS"],,-lcrypto)
> +
> + AC_TYPE_INT16_T
> + AC_TYPE_INT32_T
> {noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (THRIFT-1296) SSL detection is broken
SSL detection is broken
---
Key: THRIFT-1296
URL: https://issues.apache.org/jira/browse/THRIFT-1296
Project: Thrift
Issue Type: Bug
Components: Build Process
Affects Versions: 0.7
Environment: Ubuntu 10.04
Building Thrift against a custom toolchain (not using system packages/libraries)
Reporter: Diwaker Gupta
When using shared libraries, libssl has dependencies on libcrypto. The current
autoconf macro for checking SSL doesn't do the job:
{noformat}
configure:23665: checking for SSL_ctrl in -lssl
configure:23690: x86_64-unknown-linux-gnu-g++ -o conftest -O2 -Wall -pipe
-L -I -O2 -Wall -pipe conftest.cpp -lssl -lrt -lpthread >&5
x86_64-unknown-linux-gnu/bin/ld: warning: libcrypto.so.1.0.0, needed by
/usr/lib/libssl.so, not found (try using -rpath or -rpath-link)
{noformat}
The following patch fixes this problem:
{noformat}
+--- configure.ac
configure.ac
+@@ -312,7 +312,7 @@ dnl of the POSIX Real-Time Extensions. This seems
necessary on Linux,
+ dnl and we haven't yet found a system where this is a problem.
+ AC_CHECK_LIB(rt, clock_gettime)
+ AC_CHECK_LIB(socket, setsockopt)
+-AC_CHECK_LIB(ssl, SSL_ctrl)
++AC_CHECK_LIB(ssl, SSL_ctrl,[LIBS="-lssl -lcrypto $LIBS"],,-lcrypto)
+
+ AC_TYPE_INT16_T
+ AC_TYPE_INT32_T
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (THRIFT-1295) Duplicate include in TSocket.cpp
Duplicate include in TSocket.cpp
Key: THRIFT-1295
URL: https://issues.apache.org/jira/browse/THRIFT-1295
Project: Thrift
Issue Type: Improvement
Components: C++ - Library
Affects Versions: 0.7
Reporter: Diwaker Gupta
Priority: Trivial
Fix For: 0.8
TSocket.cpp includes netdb.in which is already included by TSocket.h. Trivial
diff:
{noformat}
--- lib/cpp/src/transport/TSocket.cpp
+++ lib/cpp/src/transport/TSocket.cpp
@@ -27,7 +27,6 @@
#include
#include
#include
-#include
#include
#include
#include
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (THRIFT-1291) Severely outdated config.sub in 0.7 distribution
[
https://issues.apache.org/jira/browse/THRIFT-1291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Diwaker Gupta updated THRIFT-1291:
--
Attachment: config.sub.0.7
config.sub.0.6
> Severely outdated config.sub in 0.7 distribution
>
>
> Key: THRIFT-1291
> URL: https://issues.apache.org/jira/browse/THRIFT-1291
> Project: Thrift
> Issue Type: Bug
> Components: Build Process, Deployment
>Affects Versions: 0.7
>Reporter: Diwaker Gupta
> Attachments: config.sub.0.6, config.sub.0.7
>
>
> The version of config.sub that is distributed with Thrift 0.7 seems to be
> from 2003, whereas the one that shipped with 0.6 is from 2008. This is
> breaking Thrift builds for us on non-standard platforms. For instance:
> {noformat}
> $ bash config.sub.0.6 arm-unknown-linux-uclibcgnueabi
> arm-unknown-linux-uclibcgnueabi
> $ bash config.sub.0.7 arm-unknown-linux-uclibcgnueabi
> Invalid configuration `arm-unknown-linux-uclibcgnueabi': machine
> `arm-unknown-linux' not recognized
> {noformat}
> The first few lines of the files are also instructive:
> {noformat}
> $ head -n 7 config.sub.0.6
> #! /bin/sh
> # Configuration validation subroutine script.
> # Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
> # 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008
> # Free Software Foundation, Inc.
> timestamp='2008-01-16'
> $ head -n 7 config.sub.0.7
> #! /bin/sh
> # Configuration validation subroutine script.
> # Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
> # 2000, 2001, 2002, 2003 Free Software Foundation, Inc.
> timestamp='2003-06-18'
> {noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (THRIFT-1291) Severely outdated config.sub in 0.7 distribution
Severely outdated config.sub in 0.7 distribution
Key: THRIFT-1291
URL: https://issues.apache.org/jira/browse/THRIFT-1291
Project: Thrift
Issue Type: Bug
Components: Build Process, Deployment
Affects Versions: 0.7
Reporter: Diwaker Gupta
The version of config.sub that is distributed with Thrift 0.7 seems to be from
2003, whereas the one that shipped with 0.6 is from 2008. This is breaking
Thrift builds for us on non-standard platforms. For instance:
{noformat}
$ bash config.sub.0.6 arm-unknown-linux-uclibcgnueabi
arm-unknown-linux-uclibcgnueabi
$ bash config.sub.0.7 arm-unknown-linux-uclibcgnueabi
Invalid configuration `arm-unknown-linux-uclibcgnueabi': machine
`arm-unknown-linux' not recognized
{noformat}
The first few lines of the files are also instructive:
{noformat}
$ head -n 7 config.sub.0.6
#! /bin/sh
# Configuration validation subroutine script.
# Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
# 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008
# Free Software Foundation, Inc.
timestamp='2008-01-16'
$ head -n 7 config.sub.0.7
#! /bin/sh
# Configuration validation subroutine script.
# Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
# 2000, 2001, 2002, 2003 Free Software Foundation, Inc.
timestamp='2003-06-18'
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (THRIFT-1250) RPC enhancements: multiple-outstanding, retries, error code etc
RPC enhancements: multiple-outstanding, retries, error code etc
---
Key: THRIFT-1250
URL: https://issues.apache.org/jira/browse/THRIFT-1250
Project: Thrift
Issue Type: Improvement
Components: Compiler (General)
Reporter: Diwaker Gupta
The current RPC model of Thrift sends the RPC requests and responses as-is,
leaving all the smartness to the Processor implementation. While this model has
the benefit of simplicity, it does have some limitations. In particular:
* There's no easy way for applications to retry a failed RPC. In fact, there's
no easy way for the RPC layer to even communicate problems to the application
(was there a transport error? did the invoked method not exist on the remote
end? some other application-specific error? time out?).
* Supporting multiple-outstanding RPCs is challenging, because the RPC layer
doesn't uniquely identify outgoing RPC requests. So when a response comes back,
there's no way to associate it with one of the outstanding RPCs.
A fairly straight-forward approach to address these issues would be to
encapsulate the RPC request/response in a wrapper with some additional
metadata. In fact, this metadata can itself be specified as a Thrift message.
Concretely, something like this:
struct RpcRequest {
// metadata
1: required i64 id;
// optional -- may be used to sanity check
2: i32 requestSize; // including payload
3: i32 payloadSize; // just the payload
// actual request, serialized
2: required binary payload;
}
IMO this would simplify the implementation of features like duplicate
detection, RPC retries, multiple-outstanding RPCs etc.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (THRIFT-1250) RPC enhancements: multiple-outstanding, retries, error code etc
[
https://issues.apache.org/jira/browse/THRIFT-1250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Diwaker Gupta updated THRIFT-1250:
--
Description:
The current RPC model of Thrift sends the RPC requests and responses as-is,
leaving all the smartness to the Processor implementation. While this model has
the benefit of simplicity, it does have some limitations. In particular:
* There's no easy way for applications to retry a failed RPC. In fact, there's
no easy way for the RPC layer to even communicate problems to the application
(was there a transport error? did the invoked method not exist on the remote
end? some other application-specific error? time out?).
* Supporting multiple-outstanding RPCs is challenging, because the RPC layer
doesn't uniquely identify outgoing RPC requests. So when a response comes back,
there's no way to associate it with one of the outstanding RPCs.
A fairly straight-forward approach to address these issues would be to
encapsulate the RPC request/response in a wrapper with some additional
metadata. In fact, this metadata can itself be specified as a Thrift message.
Concretely, something like this:
{code}
struct RpcRequest {
// metadata
1: required i64 id;
// optional -- may be used to sanity check
2: i32 requestSize; // including payload
3: i32 payloadSize; // just the payload
// actual request, serialized
2: required binary payload;
}
{code}
IMO this would simplify the implementation of features like duplicate
detection, RPC retries, multiple-outstanding RPCs etc.
was:
The current RPC model of Thrift sends the RPC requests and responses as-is,
leaving all the smartness to the Processor implementation. While this model has
the benefit of simplicity, it does have some limitations. In particular:
* There's no easy way for applications to retry a failed RPC. In fact, there's
no easy way for the RPC layer to even communicate problems to the application
(was there a transport error? did the invoked method not exist on the remote
end? some other application-specific error? time out?).
* Supporting multiple-outstanding RPCs is challenging, because the RPC layer
doesn't uniquely identify outgoing RPC requests. So when a response comes back,
there's no way to associate it with one of the outstanding RPCs.
A fairly straight-forward approach to address these issues would be to
encapsulate the RPC request/response in a wrapper with some additional
metadata. In fact, this metadata can itself be specified as a Thrift message.
Concretely, something like this:
struct RpcRequest {
// metadata
1: required i64 id;
// optional -- may be used to sanity check
2: i32 requestSize; // including payload
3: i32 payloadSize; // just the payload
// actual request, serialized
2: required binary payload;
}
IMO this would simplify the implementation of features like duplicate
detection, RPC retries, multiple-outstanding RPCs etc.
> RPC enhancements: multiple-outstanding, retries, error code etc
> ---
>
> Key: THRIFT-1250
> URL: https://issues.apache.org/jira/browse/THRIFT-1250
> Project: Thrift
> Issue Type: Improvement
> Components: Compiler (General)
>Reporter: Diwaker Gupta
>
> The current RPC model of Thrift sends the RPC requests and responses as-is,
> leaving all the smartness to the Processor implementation. While this model
> has the benefit of simplicity, it does have some limitations. In particular:
> * There's no easy way for applications to retry a failed RPC. In fact,
> there's no easy way for the RPC layer to even communicate problems to the
> application (was there a transport error? did the invoked method not exist on
> the remote end? some other application-specific error? time out?).
> * Supporting multiple-outstanding RPCs is challenging, because the RPC layer
> doesn't uniquely identify outgoing RPC requests. So when a response comes
> back, there's no way to associate it with one of the outstanding RPCs.
> A fairly straight-forward approach to address these issues would be to
> encapsulate the RPC request/response in a wrapper with some additional
> metadata. In fact, this metadata can itself be specified as a Thrift message.
> Concretely, something like this:
> {code}
> struct RpcRequest {
> // metadata
> 1: required i64 id;
> // optional -- may be used to sanity check
> 2: i32 requestSize; // including payload
> 3: i32 payloadSize; // just the payload
> // actual request, serialized
> 2: required binary payload;
> }
> {code}
> IMO this would simplify the implementation of features like duplicate
> detection, RPC retries, multiple-outstanding RPCs etc.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (THRIFT-1233) Remove unused include in generated C++ code
[ https://issues.apache.org/jira/browse/THRIFT-1233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13067747#comment-13067747 ] Diwaker Gupta commented on THRIFT-1233: --- @alexandre: Can you provide some more details about your build (include path etc?). I've built Thrift compiled C++ code with cob_style enabled and have not seen this issue. > Remove unused include in generated C++ code > --- > > Key: THRIFT-1233 > URL: https://issues.apache.org/jira/browse/THRIFT-1233 > Project: Thrift > Issue Type: Improvement > Components: C++ - Compiler > Environment: Ubuntu 11.04, latest trunk. >Reporter: Diwaker Gupta >Assignee: Jake Farrell >Priority: Trivial > Fix For: 0.7 > > Attachments: THRIFT-1233.patch > > > When using cob_style with the CPP generator, the compiler adds an include for > TTransportUtils. This include doesn't seem to be used anywhere and creates an > unnecessary dependency. It also complicates compiling Thrift generated code > on other platforms. > Patch available for review here: > https://reviews.apache.org/r/1034/ -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (THRIFT-1233) Remove unused include in generated C++ code
[ https://issues.apache.org/jira/browse/THRIFT-1233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diwaker Gupta updated THRIFT-1233: -- Attachment: THRIFT-1233.patch > Remove unused include in generated C++ code > --- > > Key: THRIFT-1233 > URL: https://issues.apache.org/jira/browse/THRIFT-1233 > Project: Thrift > Issue Type: Improvement > Components: C++ - Compiler > Environment: Ubuntu 11.04, latest trunk. >Reporter: Diwaker Gupta >Assignee: Jake Farrell >Priority: Trivial > Attachments: THRIFT-1233.patch > > > When using cob_style with the CPP generator, the compiler adds an include for > TTransportUtils. This include doesn't seem to be used anywhere and creates an > unnecessary dependency. It also complicates compiling Thrift generated code > on other platforms. > Patch available for review here: > https://reviews.apache.org/r/1034/ -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (THRIFT-1233) Remove unused include in generated C++ code
[ https://issues.apache.org/jira/browse/THRIFT-1233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diwaker Gupta reassigned THRIFT-1233: - Assignee: Jake Farrell Bump. > Remove unused include in generated C++ code > --- > > Key: THRIFT-1233 > URL: https://issues.apache.org/jira/browse/THRIFT-1233 > Project: Thrift > Issue Type: Improvement > Components: C++ - Compiler > Environment: Ubuntu 11.04, latest trunk. >Reporter: Diwaker Gupta >Assignee: Jake Farrell >Priority: Trivial > > When using cob_style with the CPP generator, the compiler adds an include for > TTransportUtils. This include doesn't seem to be used anywhere and creates an > unnecessary dependency. It also complicates compiling Thrift generated code > on other platforms. > Patch available for review here: > https://reviews.apache.org/r/1034/ -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (THRIFT-1233) Remove unused include in generated C++ code
Remove unused include in generated C++ code --- Key: THRIFT-1233 URL: https://issues.apache.org/jira/browse/THRIFT-1233 Project: Thrift Issue Type: Improvement Components: C++ - Compiler Environment: Ubuntu 11.04, latest trunk. Reporter: Diwaker Gupta Priority: Trivial When using cob_style with the CPP generator, the compiler adds an include for TTransportUtils. This include doesn't seem to be used anywhere and creates an unnecessary dependency. It also complicates compiling Thrift generated code on other platforms. Patch available for review here: https://reviews.apache.org/r/1034/ -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (THRIFT-1231) Remove bogus include
Remove bogus include Key: THRIFT-1231 URL: https://issues.apache.org/jira/browse/THRIFT-1231 Project: Thrift Issue Type: Improvement Components: C++ - Library Affects Versions: 0.6.1 Environment: Ubuntu 11.04, latest trunk Reporter: Diwaker Gupta Priority: Minor Fix For: 0.7 Attachments: THRIFT-1231.patch TAsyncChannel.h includes TTransportUtils.h, but doesn't really need/use it. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (THRIFT-1231) Remove bogus include
[ https://issues.apache.org/jira/browse/THRIFT-1231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diwaker Gupta updated THRIFT-1231: -- Attachment: THRIFT-1231.patch > Remove bogus include > > > Key: THRIFT-1231 > URL: https://issues.apache.org/jira/browse/THRIFT-1231 > Project: Thrift > Issue Type: Improvement > Components: C++ - Library >Affects Versions: 0.6.1 > Environment: Ubuntu 11.04, latest trunk >Reporter: Diwaker Gupta >Priority: Minor > Fix For: 0.7 > > Attachments: THRIFT-1231.patch > > > TAsyncChannel.h includes TTransportUtils.h, but doesn't really need/use it. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[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
[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-1195) Allow users to act on client connects/disconnects
[
https://issues.apache.org/jira/browse/THRIFT-1195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046273#comment-13046273
]
Diwaker Gupta commented on THRIFT-1195:
---
Sure. As long as there's a reasonable hook, I'm not particularly attached to a
specific implementation.
> Allow users to act on client connects/disconnects
> -
>
> Key: THRIFT-1195
> URL: https://issues.apache.org/jira/browse/THRIFT-1195
> Project: Thrift
> Issue Type: New Feature
> Components: Java - Library
> Environment: Ubuntu 11.04, Sun JVM
>Reporter: Diwaker Gupta
> Attachments: THRIFT-1195-v0.patch
>
>
> As it stands, the Java library doesn't provide any hooks to detect exactly
> when a client got connected/disconnected. For many services, this information
> is both useful and required for things like cleaning up state.
> There are of course many possible ways to address this. Here are some
> thoughts from my initial mail on the topic:
> {noformat}
> Suppose I have a stateful service and I'd like to clean up some state
> when a client disconnects. IIUC, there's no straight forward way to do
> this with Thrift. I'd love to hear what others have done in similar
> situations.
> I'm trying to figure out if there's a way to support this without
> modifying Thrift core (this is all with the Thrift Java library):
> * my first instinct was to extend TFramedTransport with a custom
> factory that allows adding "listeners" that can be fired on a close.
> Unfortunately it seems like TFramedTransport.close is either never
> called, or not called when a client disconnects. The actual socket
> close is wrapped up inside a TNonblockingSocket within the FrameBuffer
> managed by TNonblockingServer. So this approach doesn't work.
> * Since the client socket is generated by
> TNonblockingServerSocket.accept, I next considered overriding
> accemptImpl() in a custom ServerSocket. This poses other problems --
> because much of the state in TNonblockingServerSocket is private, I
> need to use super.acceptImpl() to obtain the TNonblockingSocket (or
> reimplement everything). This in turn is not helpful because I then
> need to wrap the returned TNonblockingSocket in another "forwarding
> object" such that the listeners can be fired when the socket is
> closed.
> {noformat}
> Unfortunately I did not find any way to do this without modifying Thrift
> itself, hence this issue. After evaluating several different alternatives, I
> decided to go with the least intrusive approach, which is implemented in the
> attached patch. Basically users can add open/close handlers as part of the
> Args supplied to TNonblockingServer. The server code then invokes the
> callbacks when appropriate. I realize this approach is not perfect so I'm
> eager to get some feedback and hear some alternatives.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (THRIFT-1195) Allow users to act on client connects/disconnects
[
https://issues.apache.org/jira/browse/THRIFT-1195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Diwaker Gupta updated THRIFT-1195:
--
Attachment: THRIFT-1195-v0.patch
> Allow users to act on client connects/disconnects
> -
>
> Key: THRIFT-1195
> URL: https://issues.apache.org/jira/browse/THRIFT-1195
> Project: Thrift
> Issue Type: New Feature
> Components: Java - Library
> Environment: Ubuntu 11.04, Sun JVM
>Reporter: Diwaker Gupta
> Attachments: THRIFT-1195-v0.patch
>
>
> As it stands, the Java library doesn't provide any hooks to detect exactly
> when a client got connected/disconnected. For many services, this information
> is both useful and required for things like cleaning up state.
> There are of course many possible ways to address this. Here are some
> thoughts from my initial mail on the topic:
> {noformat}
> Suppose I have a stateful service and I'd like to clean up some state
> when a client disconnects. IIUC, there's no straight forward way to do
> this with Thrift. I'd love to hear what others have done in similar
> situations.
> I'm trying to figure out if there's a way to support this without
> modifying Thrift core (this is all with the Thrift Java library):
> * my first instinct was to extend TFramedTransport with a custom
> factory that allows adding "listeners" that can be fired on a close.
> Unfortunately it seems like TFramedTransport.close is either never
> called, or not called when a client disconnects. The actual socket
> close is wrapped up inside a TNonblockingSocket within the FrameBuffer
> managed by TNonblockingServer. So this approach doesn't work.
> * Since the client socket is generated by
> TNonblockingServerSocket.accept, I next considered overriding
> accemptImpl() in a custom ServerSocket. This poses other problems --
> because much of the state in TNonblockingServerSocket is private, I
> need to use super.acceptImpl() to obtain the TNonblockingSocket (or
> reimplement everything). This in turn is not helpful because I then
> need to wrap the returned TNonblockingSocket in another "forwarding
> object" such that the listeners can be fired when the socket is
> closed.
> {noformat}
> Unfortunately I did not find any way to do this without modifying Thrift
> itself, hence this issue. After evaluating several different alternatives, I
> decided to go with the least intrusive approach, which is implemented in the
> attached patch. Basically users can add open/close handlers as part of the
> Args supplied to TNonblockingServer. The server code then invokes the
> callbacks when appropriate. I realize this approach is not perfect so I'm
> eager to get some feedback and hear some alternatives.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (THRIFT-1195) Allow users to act on client connects/disconnects
Allow users to act on client connects/disconnects
-
Key: THRIFT-1195
URL: https://issues.apache.org/jira/browse/THRIFT-1195
Project: Thrift
Issue Type: New Feature
Components: Java - Library
Environment: Ubuntu 11.04, Sun JVM
Reporter: Diwaker Gupta
As it stands, the Java library doesn't provide any hooks to detect exactly when
a client got connected/disconnected. For many services, this information is
both useful and required for things like cleaning up state.
There are of course many possible ways to address this. Here are some thoughts
from my initial mail on the topic:
{noformat}
Suppose I have a stateful service and I'd like to clean up some state
when a client disconnects. IIUC, there's no straight forward way to do
this with Thrift. I'd love to hear what others have done in similar
situations.
I'm trying to figure out if there's a way to support this without
modifying Thrift core (this is all with the Thrift Java library):
* my first instinct was to extend TFramedTransport with a custom
factory that allows adding "listeners" that can be fired on a close.
Unfortunately it seems like TFramedTransport.close is either never
called, or not called when a client disconnects. The actual socket
close is wrapped up inside a TNonblockingSocket within the FrameBuffer
managed by TNonblockingServer. So this approach doesn't work.
* Since the client socket is generated by
TNonblockingServerSocket.accept, I next considered overriding
accemptImpl() in a custom ServerSocket. This poses other problems --
because much of the state in TNonblockingServerSocket is private, I
need to use super.acceptImpl() to obtain the TNonblockingSocket (or
reimplement everything). This in turn is not helpful because I then
need to wrap the returned TNonblockingSocket in another "forwarding
object" such that the listeners can be fired when the socket is
closed.
{noformat}
Unfortunately I did not find any way to do this without modifying Thrift
itself, hence this issue. After evaluating several different alternatives, I
decided to go with the least intrusive approach, which is implemented in the
attached patch. Basically users can add open/close handlers as part of the Args
supplied to TNonblockingServer. The server code then invokes the callbacks when
appropriate. I realize this approach is not perfect so I'm eager to get some
feedback and hear some alternatives.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (THRIFT-1095) It should be easy to serialization/deserialize Thrift structs to/from Java I/O streams
[ https://issues.apache.org/jira/browse/THRIFT-1095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diwaker Gupta updated THRIFT-1095: -- Priority: Trivial (was: Major) Description: Update: in retrospect, the readObject/writeObject calls are likely good enough for most cases. Feel free to close as won't fix. See the ThriftCodec by Twitter: http://twitter.github.com/commons/apidocs/index.html#com.twitter.common.io.ThriftCodec It really belongs in the core Thrift Java library. was: See the ThriftCodec by Twitter: http://twitter.github.com/commons/apidocs/index.html#com.twitter.common.io.ThriftCodec It really belongs in the core Thrift Java library. > It should be easy to serialization/deserialize Thrift structs to/from Java > I/O streams > -- > > Key: THRIFT-1095 > URL: https://issues.apache.org/jira/browse/THRIFT-1095 > Project: Thrift > Issue Type: Improvement > Components: Java - Library >Reporter: Diwaker Gupta >Priority: Trivial > > Update: in retrospect, the readObject/writeObject calls are likely good > enough for most cases. Feel free to close as won't fix. > See the ThriftCodec by Twitter: > http://twitter.github.com/commons/apidocs/index.html#com.twitter.common.io.ThriftCodec > It really belongs in the core Thrift Java library. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (THRIFT-1095) It should be easy to serialization/deserialize Thrift structs to/from Java I/O streams
It should be easy to serialization/deserialize Thrift structs to/from Java I/O streams -- Key: THRIFT-1095 URL: https://issues.apache.org/jira/browse/THRIFT-1095 Project: Thrift Issue Type: Improvement Components: Java - Library Reporter: Diwaker Gupta See the ThriftCodec by Twitter: http://twitter.github.com/commons/apidocs/index.html#com.twitter.common.io.ThriftCodec It really belongs in the core Thrift Java library. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (THRIFT-363) Maven Deploy
[ https://issues.apache.org/jira/browse/THRIFT-363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13007149#comment-13007149 ] Diwaker Gupta commented on THRIFT-363: -- Bump. Can someone familiar with the issue provide an update -- is it a problem of the right credentials or do some bits in the Thrift build code need to still change? Would really like to see this happen in time for the next release. > Maven Deploy > > > Key: THRIFT-363 > URL: https://issues.apache.org/jira/browse/THRIFT-363 > Project: Thrift > Issue Type: Improvement > Components: Java - Library >Reporter: Gary Rudolph >Assignee: Jake Farrell > Fix For: 0.7 > > Attachments: THRIFT-363.patch, THRIFT-363.patch, THRIFT-363.patch, > THRIFT-363.patch, THRIFT-363.patch, THRIFT-363.patch, THRIFT-363.patch, > THRIFT-363.patch, pom.1.patch > > > Please, deploy libthrift into a public maven repository. Preferably, to Maven > central, but if not at least the Apache. > Maven Central: > http://maven.apache.org/guides/mini/guide-central-repository-upload.html > Apache Incubator Repository: > http://people.apache.org/repo/m2-incubating-repository/ > The following is a sample pom.xml: > http://maven.apache.org/POM/4.0.0"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > http://maven.apache.org/maven-v4_0_0.xsd";> > 4.0.0 > org.facebook.thrift > libthrift > 0.1-20090310 > jar > Apache Thrift Library > http://incubator.apache.org/thrift/ > Thrift is a software framework for scalable cross-language > services development. It combines a software stack with a code generation > engine to build services that work efficiently and seamlessly between C++, > Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, Smalltalk, and > OCaml > > > The Apache Software License, Version 2.0 > > http://www.apache.org/licenses/LICENSE-2.0.txt > repo > > > > > http://svn.apache.org/repos/asf/incubator/thrift/trunk > > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (THRIFT-627) should c++ have setters for optional fields?
[ https://issues.apache.org/jira/browse/THRIFT-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004904#comment-13004904 ] Diwaker Gupta commented on THRIFT-627: -- I've cleaned up the patch and incorporated David's comments. It can be reviewed here: https://github.com/maginatics/thrift/commit/0b81de84b581c99daeac78526890d4c439611722 Once the patch is approved, I can attach it here in JIRA (I find attached patches extremely hard to review). > should c++ have setters for optional fields? > > > Key: THRIFT-627 > URL: https://issues.apache.org/jira/browse/THRIFT-627 > Project: Thrift > Issue Type: Improvement > Components: C++ - Compiler > Environment: c++ >Reporter: Ben Taitelbaum >Assignee: David Reiss > Attachments: thrift-627_0.5.x.patch, thrift-627_trunk.patch > > > It seems non-intuitive to me to have to set __isset.someField = true after > setting an optional field someField on a struct. Would it make sense to have > a set_someField method that would both set the field and modify __isset? > One of the cases for this is for when a field goes from being required to > being optional, and it's easy to forget to set __isset in the code. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (THRIFT-1073) Running 'ant javadoc' inside 'lib/java' fails
Running 'ant javadoc' inside 'lib/java' fails
-
Key: THRIFT-1073
URL: https://issues.apache.org/jira/browse/THRIFT-1073
Project: Thrift
Issue Type: Improvement
Components: Java - Library
Environment: Ubuntu 10.10
Reporter: Diwaker Gupta
Priority: Trivial
Running 'ant javadoc' under 'lib/java' fails:
{noformat}
Buildfile: /home/diwaker/local/thrift/lib/java/build.xml
init:
javadoc:
[javadoc] Generating Javadoc
BUILD FAILED
/home/diwaker/local/thrift/lib/java/build.xml:146: Reference
ivy.compile.classpath not found.
{noformat}
Here's a trivial patch that fixes the problem:
{noformat}
diwaker@whitney:~/local/thrift/lib/java(develop)$ cat /tmp/thrift.patch
diff --git lib/java/build.xml lib/java/build.xml
index 7c66438..f0b09b4 100644
--- lib/java/build.xml
+++ lib/java/build.xml
@@ -137,7 +137,7 @@
-
+
http://www.atlassian.com/software/jira
