[jira] [Updated] (THRIFT-3099) cmake build is broken on FreeBSD
[
https://issues.apache.org/jira/browse/THRIFT-3099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King, III updated THRIFT-3099:
---
Component/s: Test Suite
C glib - Library
cmake build is broken on FreeBSD
Key: THRIFT-3099
URL: https://issues.apache.org/jira/browse/THRIFT-3099
Project: Thrift
Issue Type: Bug
Components: C glib - Library, Test Suite
Affects Versions: 1.0
Environment: FreeBSD/amd64 10.1-STABLE
C++ compiler: FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032)
20140512
Boost 1.55.0
cmake 3.1.3
Reporter: Marco Molteni
Cmake build is broken on FreeBSD.
Among the problems:
h4. Building the c_glib tests require to specify the Boost include directory
{noformat}
Building CXX object
lib/c_glib/test/CMakeFiles/testgenc_cpp.dir/gen-cpp/ThriftTest.cpp.o
In file included from
/home/marco/src/thrift.marco.hg/thebuild/lib/c_glib/test/gen-cpp/ThriftTest.cpp:7:
In file included from
/home/marco/src/thrift.marco.hg/thebuild/lib/c_glib/test/gen-cpp/ThriftTest.h:10:
In file included from
/home/marco/src/thrift.marco.hg/lib/cpp/src/thrift/TDispatchProcessor.h:22:
In file included from
/home/marco/src/thrift.marco.hg/lib/cpp/src/thrift/TProcessor.h:24:
In file included from
/home/marco/src/thrift.marco.hg/lib/cpp/src/thrift/protocol/TProtocol.h:23:
In file included from
/home/marco/src/thrift.marco.hg/lib/cpp/src/thrift/transport/TTransport.h:23:
/home/marco/src/thrift.marco.hg/lib/cpp/src/thrift/Thrift.h:45:10: fatal
error: 'boost/utility/enable_if.hpp' file not found
#include boost/utility/enable_if.hpp
{noformat}
h4. Compiler complaints about unspecified shared_ptr
- Compiler is confused by shared_ptr, it wants boost::shared_ptr (same
problem for MacOSX, which uses Clang as FreeBSD):
{noformat}
/home/marco/src/thrift.marco.hg/lib/c_glib/test/testthrifttestclient.cpp:594:5:
error: reference to 'shared_ptr' is ambiguous
shared_ptrTProtocolFactory protocolFactory(new
TBinaryProtocolFactory());
^
/usr/include/c++/v1/memory:3750:29: note: candidate found by name lookup is
'std::__1::shared_ptr'
class _LIBCPP_TYPE_VIS_ONLY shared_ptr
^
/usr/local/include/boost/smart_ptr/shared_ptr.hpp:722:36: note: candidate
found by name lookup is 'boost::shared_ptr'
templateclass Y friend class shared_ptr;
{noformat}
h4. libevent and TestClient
{noformat}
Linking CXX executable ../../bin/TestClient
../../lib/libcrosstestgencpp.a(ThriftTest_types.cpp.o): In function
`std::__1::__tree_node_basevoid**
std::__1::__treestd::__1::__value_typethrift::test::Insanity,
...
/home/marco/src/thrift.marco.hg/thebuild/test/cpp/gen-cpp/ThriftTest_types.cpp:
...
undefined reference to
`thrift::test::Insanity::operator(thrift::test::Insanity const) const'
{noformat}
It seems that Clang and gcc (compliers or linkers, haven't investigated) have
a slightly different behavior as below:
On FreeBSD:
{noformat}
codino% for i in lib/*.a; do echo $i; nm --demangle $i | grep
'Insanity::operator'; done
lib/libcrossstressgencpp.a
lib/libcrosstestgencpp.a
U thrift::test::Insanity::operator(thrift::test::Insanity
const) const
lib/liblibparse.a
lib/libtestgenc.a
lib/libtestgenc_cpp.a
U thrift::test::Insanity::operator(thrift::test::Insanity
const) const
lib/libtestgencpp.a
U thrift::test::Insanity::operator(thrift::test::Insanity
const) const
T thrift::test::Insanity::operator(thrift::test::Insanity
const) const
lib/libtestgencpp_cob.a
lib/libthrift.a
lib/libthrift_c_glib.a
lib/libthriftnb.a
lib/libthriftz.a
{noformat}
On Linux:
{noformat}
for i in lib/*.a; do echo $i; nm --demangle $i | grep 'Insanity::operator';
done
lib/libcrossstressgencpp.a
lib/libcrosstestgencpp.a
lib/liblibparse.a
lib/libtestgencpp.a
U thrift::test::Insanity::operator(thrift::test::Insanity
const) const
T thrift::test::Insanity::operator(thrift::test::Insanity
const) const
lib/libtestgencpp_cob.a
lib/libthrift.a
lib/libthriftnb.a
lib/libthriftz.a
{noformat}
Function {{Insanity::operator}} is defined in two indentical files:
{noformat}
lib/cpp/test/ThriftTest_extras.cpp
test/cpp/src/ThriftTest_extras.cpp
{noformat}
Solved by adding {{ThriftTest_extras.cpp}} also to library
{{crosstestgencpp}}. Tested on Linux, no complaints.
Upcoming pull request.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (THRIFT-3168) Fix Maven POM
[ https://issues.apache.org/jira/browse/THRIFT-3168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King, III resolved THRIFT-3168. Resolution: Duplicate Assignee: Jake Farrell I reopened THRIFT-2269 and linked this to it as a duplicate. Fix Maven POM - Key: THRIFT-3168 URL: https://issues.apache.org/jira/browse/THRIFT-3168 Project: Thrift Issue Type: Bug Affects Versions: 0.9.2 Reporter: Maarten Billemont Assignee: Jake Farrell Fix For: 0.9.3 1. THRIFT-2269 was not fixed properly. Sources are supposed to be deployed using a jar type. maven-dependency-plugin cannot resolve them otherwise and IDEs such as IntelliJ IDEA are unable to resolve or even manually attach sources with a src extension/type. 2. Between 0.9.1 and 0.9.2, the POM for libthrift was modified to remove a dependency on commons-lang3. As a result, the code generated by libthrift no longer builds as it misses this dependency. The dependency needs to be restored, or whatever reason resulted in its removal re-evaluated to take this requirement into account. Personally, I'd prefer if we could just drop this dependency entirely and use native Java language utilities such as `Objects` to solve the problems `commons-lang3` is trying to solve. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-3136) thrift installation problem on mac
[ https://issues.apache.org/jira/browse/THRIFT-3136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14597592#comment-14597592 ] James E. King, III commented on THRIFT-3136: Could you document the exact operating system version that you can reproduce this in? thrift installation problem on mac -- Key: THRIFT-3136 URL: https://issues.apache.org/jira/browse/THRIFT-3136 Project: Thrift Issue Type: Question Components: Build Process Environment: macbook air Reporter: damianlau ./bootstrap.sh and then ./configure i got this error message: ./configure: line 17747: syntax error near unexpected token `QT,' ./configure: line 17747: `PKG_CHECK_MODULES(QT, QtCore = 4.3, QtNetwork = 4.3, have_qt=yes, have_qt=no)' --without-qt4 doesn't work... any help? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (THRIFT-3136) thrift installation problem on mac
[ https://issues.apache.org/jira/browse/THRIFT-3136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King, III updated THRIFT-3136: --- Component/s: Build Process thrift installation problem on mac -- Key: THRIFT-3136 URL: https://issues.apache.org/jira/browse/THRIFT-3136 Project: Thrift Issue Type: Question Components: Build Process Environment: macbook air Reporter: damianlau ./bootstrap.sh and then ./configure i got this error message: ./configure: line 17747: syntax error near unexpected token `QT,' ./configure: line 17747: `PKG_CHECK_MODULES(QT, QtCore = 4.3, QtNetwork = 4.3, have_qt=yes, have_qt=no)' --without-qt4 doesn't work... any help? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (THRIFT-2950) Thrift's PHP generated entity does not serialize SET type correctly
[
https://issues.apache.org/jira/browse/THRIFT-2950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King, III updated THRIFT-2950:
---
Component/s: PHP - Compiler
Thrift's PHP generated entity does not serialize SET type correctly
Key: THRIFT-2950
URL: https://issues.apache.org/jira/browse/THRIFT-2950
Project: Thrift
Issue Type: Bug
Components: PHP - Compiler
Reporter: Dmitry Kiselev
idl:
{noformat}
struct TTestEntity {
1: string id
2: setstring data
}
{noformat}
php code generation works okay and we can set data
{noformat}
$entity = new TTestEntity();
$entity-id = hello;
$entity-data = array(element1, element2);
$buffer = new TMemoryBuffer();
$entity-write(new TJSONProtocol($buffer));
echo $buffer-getBuffer();
{noformat}
but resulting JSON does not contain the set elements values:
{noformat}
{1:{str:hello},2:{set:[str,2,0,1]}}
{noformat}
If found the code generated by thrift that creates writes a string for SET:
{code}
foreach ($this-collection as $iter6 = $iter7)
{
if (is_scalar($iter7)) {
$xfer += $output-writeString($iter6);
} else {
$xfer += $output-writeString($iter7);
}
}
{code}
I can't explain why there is a check for is_scalar, but when array item value
is string, number or boolean it writes array item key instead of value.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (THRIFT-3055) Apache Thrift Logo
[ https://issues.apache.org/jira/browse/THRIFT-3055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King, III updated THRIFT-3055: --- Component/s: Wish List Apache Thrift Logo -- Key: THRIFT-3055 URL: https://issues.apache.org/jira/browse/THRIFT-3055 Project: Thrift Issue Type: Brainstorming Components: Wish List Reporter: Jake Farrell Assignee: Jake Farrell -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (THRIFT-1774) Sasl Transport client would hang when trying to connect non-sasl transport server
[ https://issues.apache.org/jira/browse/THRIFT-1774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King, III resolved THRIFT-1774. Resolution: Incomplete Resolving as incomplete until additional information can be added by the reporter as requested by [~jensg]. Sasl Transport client would hang when trying to connect non-sasl transport server - Key: THRIFT-1774 URL: https://issues.apache.org/jira/browse/THRIFT-1774 Project: Thrift Issue Type: Bug Affects Versions: 0.7 Reporter: Alan Choi We noticed that when a thrift sasl transport client would hang when it tries to connect to a non-sasl transport server. It would be better if it can raise an exception.. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (THRIFT-1) Fully-asychronous client and server
[ https://issues.apache.org/jira/browse/THRIFT-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King, III updated THRIFT-1: Component/s: Wish List Fully-asychronous client and server --- Key: THRIFT-1 URL: https://issues.apache.org/jira/browse/THRIFT-1 Project: Thrift Issue Type: New Feature Components: Wish List Environment: All Reporter: David Reiss All Thrift servers currently require a thread to be tied up for every outstanding request being serviced. In addition, all clients have the same requirement, but workarounds are easier. This is also the first JIRA issue in the Thrift project. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (THRIFT-2269) Can deploy libthrift-source.jar to maven center repository
[ https://issues.apache.org/jira/browse/THRIFT-2269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King, III reopened THRIFT-2269: Can deploy libthrift-source.jar to maven center repository -- Key: THRIFT-2269 URL: https://issues.apache.org/jira/browse/THRIFT-2269 Project: Thrift Issue Type: Improvement Components: Build Process Affects Versions: 0.9.1 Reporter: vongosling Assignee: Jake Farrell Fix For: 0.9.2 Now,I can only find libthrift-0.9.1-tar.gz.src in mvn repository,but it can not find by mainly IDE,such as eclipse,intellij idea,Netbean,can you improve this problem,thanks~ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-3185) typedef is ignored in d.ts files for TypeScript.
[
https://issues.apache.org/jira/browse/THRIFT-3185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14597587#comment-14597587
]
James E. King, III commented on THRIFT-3185:
What is the correct component to categorize this under?
typedef is ignored in d.ts files for TypeScript.
Key: THRIFT-3185
URL: https://issues.apache.org/jira/browse/THRIFT-3185
Project: Thrift
Issue Type: Improvement
Reporter: HIRANO Satoshi
TypeScript support is very valuable for us.
But, currently d.ts files for TypeScript does not include any info on
typedefs defined in IDLs.
For example, we have foo.idl like this.
typedef string userID
struct Foo {1: userID s }
Currently this is compiled into foo.d.ts like this.
declare class Foo { s: string; }
I should be like this, or we have to use string instead of meaningfull userID.
declare type userID = string;
declare class Foo { s: userID; }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (THRIFT-2977) C++ Non-blocking server core dump - signal 6
[
https://issues.apache.org/jira/browse/THRIFT-2977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King, III updated THRIFT-2977:
---
Priority: Critical (was: Major)
C++ Non-blocking server core dump - signal 6
Key: THRIFT-2977
URL: https://issues.apache.org/jira/browse/THRIFT-2977
Project: Thrift
Issue Type: Bug
Components: C++ - Library
Affects Versions: 0.9.2
Environment: CentOS 6.6 x86_64
Reporter: Hung Vo
Priority: Critical
Fix For: 0.9.3
Our C++ Non-blocking server got a signal 6 core-dump.
Please help to identify the problem.
Thanks.
gdb full back-tracing as follow:
#0 0x7f9b96edb625 in raise () from /lib64/libc.so.6
No symbol table info available.
#1 0x7f9b96edcd8d in abort () from /lib64/libc.so.6
No symbol table info available.
#2 0x7f9b96ed474e in __assert_fail_base () from /lib64/libc.so.6
No symbol table info available.
#3 0x7f9b96ed4810 in __assert_fail () from /lib64/libc.so.6
No symbol table info available.
#4 0x00535927 in
apache::thrift::server::TNonblockingServer::TConnection::workSocket
(this=0x7f649015a330) at thrift_src/thrift/server/TNonblockingServer.cpp:504
framing = {buf = \320;\230\226, size = 2526559184}
sent = 0
__PRETTY_FUNCTION__ = void
apache::thrift::server::TNonblockingServer::TConnection::workSocket()
got = 0
left = 0
fetch = 0
#5 0x0053a83f in
apache::thrift::server::TNonblockingServer::TConnection::eventHandler
(fd=136, v=0x7f649015a330) at
thrift_src/thrift/server/TNonblockingServer.cpp:276
__PRETTY_FUNCTION__ = static void
apache::thrift::server::TNonblockingServer::TConnection::eventHandler(int,
short int, void*)
#6 0x00556943 in event_persist_closure (base=0x7f6490151800,
ev=0x7f649015a360) at src/event.c:1297
__func__ = event_persist_closure
#7 0x00556a58 in event_process_active_single_queue
(base=0x7f6490151800, activeq=0x7f6490151c40) at src/event.c:1341
ev = 0x7f649015a360
count = 1
__func__ = event_process_active_single_queue
#8 0x00556d2d in event_process_active (base=0x7f6490151800) at
src/event.c:1416
activeq = 0x7f6490151c40
i = 0
c = 0
#9 0x00557397 in event_base_loop (base=0x7f6490151800, flags=0) at
src/event.c:1617
n = 1
evsel = 0x7bcc60
tv = {tv_sec = 140069890758272, tv_usec = 140069890757312}
tv_p = 0x0
res = 0
done = 0
retval = 0
__func__ = event_base_loop
#10 0x005395d2 in apache::thrift::server::TNonblockingIOThread::run
(this=0x7f6490151680) at thrift_src/thrift/server/TNonblockingServer.cpp:1534
No locals.
#11 0x005387a2 in apache::thrift::server::TNonblockingServer::serve
(this=0x7f6490151070, host=0x13b4078 192.168.1.30) at
thrift_src/thrift/server/TNonblockingServer.cpp:1275
No locals.
#12 0x005013c9 in ThriftServer::start (this=0x13b3050) at
ThriftServer.cpp:35
threadFactory = {px = 0x7f64900010c0, pn = {pi_ = 0x7f6490001120}}
#13 0x0050147e in ThriftServer::pthread_run_serve (This=0x13b3050) at
ThriftServer.cpp:44
No locals.
#14 0x7f9b972449d1 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#15 0x7f9b96f918fd in clone () from /lib64/libc.so.6
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (THRIFT-2977) C++ Non-blocking server core dump - signal 6
[
https://issues.apache.org/jira/browse/THRIFT-2977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King, III updated THRIFT-2977:
---
Component/s: C++ - Library
C++ Non-blocking server core dump - signal 6
Key: THRIFT-2977
URL: https://issues.apache.org/jira/browse/THRIFT-2977
Project: Thrift
Issue Type: Bug
Components: C++ - Library
Affects Versions: 0.9.2
Environment: CentOS 6.6 x86_64
Reporter: Hung Vo
Fix For: 0.9.3
Our C++ Non-blocking server got a signal 6 core-dump.
Please help to identify the problem.
Thanks.
gdb full back-tracing as follow:
#0 0x7f9b96edb625 in raise () from /lib64/libc.so.6
No symbol table info available.
#1 0x7f9b96edcd8d in abort () from /lib64/libc.so.6
No symbol table info available.
#2 0x7f9b96ed474e in __assert_fail_base () from /lib64/libc.so.6
No symbol table info available.
#3 0x7f9b96ed4810 in __assert_fail () from /lib64/libc.so.6
No symbol table info available.
#4 0x00535927 in
apache::thrift::server::TNonblockingServer::TConnection::workSocket
(this=0x7f649015a330) at thrift_src/thrift/server/TNonblockingServer.cpp:504
framing = {buf = \320;\230\226, size = 2526559184}
sent = 0
__PRETTY_FUNCTION__ = void
apache::thrift::server::TNonblockingServer::TConnection::workSocket()
got = 0
left = 0
fetch = 0
#5 0x0053a83f in
apache::thrift::server::TNonblockingServer::TConnection::eventHandler
(fd=136, v=0x7f649015a330) at
thrift_src/thrift/server/TNonblockingServer.cpp:276
__PRETTY_FUNCTION__ = static void
apache::thrift::server::TNonblockingServer::TConnection::eventHandler(int,
short int, void*)
#6 0x00556943 in event_persist_closure (base=0x7f6490151800,
ev=0x7f649015a360) at src/event.c:1297
__func__ = event_persist_closure
#7 0x00556a58 in event_process_active_single_queue
(base=0x7f6490151800, activeq=0x7f6490151c40) at src/event.c:1341
ev = 0x7f649015a360
count = 1
__func__ = event_process_active_single_queue
#8 0x00556d2d in event_process_active (base=0x7f6490151800) at
src/event.c:1416
activeq = 0x7f6490151c40
i = 0
c = 0
#9 0x00557397 in event_base_loop (base=0x7f6490151800, flags=0) at
src/event.c:1617
n = 1
evsel = 0x7bcc60
tv = {tv_sec = 140069890758272, tv_usec = 140069890757312}
tv_p = 0x0
res = 0
done = 0
retval = 0
__func__ = event_base_loop
#10 0x005395d2 in apache::thrift::server::TNonblockingIOThread::run
(this=0x7f6490151680) at thrift_src/thrift/server/TNonblockingServer.cpp:1534
No locals.
#11 0x005387a2 in apache::thrift::server::TNonblockingServer::serve
(this=0x7f6490151070, host=0x13b4078 192.168.1.30) at
thrift_src/thrift/server/TNonblockingServer.cpp:1275
No locals.
#12 0x005013c9 in ThriftServer::start (this=0x13b3050) at
ThriftServer.cpp:35
threadFactory = {px = 0x7f64900010c0, pn = {pi_ = 0x7f6490001120}}
#13 0x0050147e in ThriftServer::pthread_run_serve (This=0x13b3050) at
ThriftServer.cpp:44
No locals.
#14 0x7f9b972449d1 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#15 0x7f9b96f918fd in clone () from /lib64/libc.so.6
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (THRIFT-3197) keepAliveTime is hard coded as 60 sec in TThreadPoolServer
[
https://issues.apache.org/jira/browse/THRIFT-3197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King, III updated THRIFT-3197:
---
Component/s: Java - Library
keepAliveTime is hard coded as 60 sec in TThreadPoolServer
--
Key: THRIFT-3197
URL: https://issues.apache.org/jira/browse/THRIFT-3197
Project: Thrift
Issue Type: Bug
Components: Java - Library
Reporter: Pankaj Kumar
Attachments: THRIFT-3197-V2.patch, THRIFT-3197.patch
While creating ThreadPoolExecutor in TThreadPoolServer, keepAliveTime is hard
coded as 60 sec.
{code}
private static ExecutorService createDefaultExecutorService(Args args) {
SynchronousQueueRunnable executorQueue =
new SynchronousQueueRunnable();
return new ThreadPoolExecutor(args.minWorkerThreads,
args.maxWorkerThreads,
60,
TimeUnit.SECONDS,
executorQueue);
}
{code}
It should be args.stopTimeoutVal
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (THRIFT-3197) keepAliveTime is hard coded as 60 sec in TThreadPoolServer
[
https://issues.apache.org/jira/browse/THRIFT-3197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King, III updated THRIFT-3197:
---
Patch Info: Patch Available
keepAliveTime is hard coded as 60 sec in TThreadPoolServer
--
Key: THRIFT-3197
URL: https://issues.apache.org/jira/browse/THRIFT-3197
Project: Thrift
Issue Type: Bug
Components: Java - Library
Reporter: Pankaj Kumar
Attachments: THRIFT-3197-V2.patch, THRIFT-3197.patch
While creating ThreadPoolExecutor in TThreadPoolServer, keepAliveTime is hard
coded as 60 sec.
{code}
private static ExecutorService createDefaultExecutorService(Args args) {
SynchronousQueueRunnable executorQueue =
new SynchronousQueueRunnable();
return new ThreadPoolExecutor(args.minWorkerThreads,
args.maxWorkerThreads,
60,
TimeUnit.SECONDS,
executorQueue);
}
{code}
It should be args.stopTimeoutVal
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (THRIFT-3055) Apache Thrift Logo
[ https://issues.apache.org/jira/browse/THRIFT-3055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King, III updated THRIFT-3055: --- Issue Type: Brainstorming (was: New Feature) Apache Thrift Logo -- Key: THRIFT-3055 URL: https://issues.apache.org/jira/browse/THRIFT-3055 Project: Thrift Issue Type: Brainstorming Reporter: Jake Farrell Assignee: Jake Farrell -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-3055) Apache Thrift Logo
[ https://issues.apache.org/jira/browse/THRIFT-3055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14597613#comment-14597613 ] James E. King, III commented on THRIFT-3055: How about something along these lines? http://strategicbusinesssuccess.com/wp-content/uploads/puzzle-bridge-for-web-1024x973.png Don't need words or the silly background. It doesn't even have to be a puzzle piece - it could be a handshake, or a yin/yang-like symbol. Apache Thrift Logo -- Key: THRIFT-3055 URL: https://issues.apache.org/jira/browse/THRIFT-3055 Project: Thrift Issue Type: New Feature Reporter: Jake Farrell Assignee: Jake Farrell -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (THRIFT-3163) Build failure due to ylwrap being called with wrong arguments
[ https://issues.apache.org/jira/browse/THRIFT-3163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King, III updated THRIFT-3163: --- Component/s: Compiler (General) Build failure due to ylwrap being called with wrong arguments - Key: THRIFT-3163 URL: https://issues.apache.org/jira/browse/THRIFT-3163 Project: Thrift Issue Type: Bug Components: Compiler (General) Environment: Ubuntu 15.04 automake 1.14.1 GNU Make 4.0 ylwrap 2013-01-12.17 Reporter: Tomasz Kupczyk Priority: Minor Labels: build-failure Hey, when trying to build on fresh Ubuntu 15.04 installation I got this problem: floyd@floyd-VirtualBox:~/thrift$ make make all-recursive make[1]: Entering directory '/home/floyd/thrift' Making all in compiler/cpp make[2]: Entering directory '/home/floyd/thrift/compiler/cpp' make all-am make[3]: Entering directory '/home/floyd/thrift/compiler/cpp' \ \ /bin/bash ../../ylwrap `test -f 'src/thriftl.ll' || echo './'`src/thriftl.ll .c thriftl.cc -- /bin/bash /home/floyd/thrift/missing flex /home/floyd/thrift/compiler/cpp/src/thriftl.ll:266: warning, rule cannot be matched /home/floyd/thrift/compiler/cpp/src/thriftl.ll:285: warning, rule cannot be matched /home/floyd/thrift/compiler/cpp/src/thriftl.ll:413: warning, rule cannot be matched lex.yythriftl.cc is unchanged g++ -DHAVE_CONFIG_H -I. -I../.. -I../../lib/cpp/src/thrift -I./src -Wall -Wno-sign-compare -Wno-unused -g -O2 -std=c++11 -MT libparse_a-thriftl.o -MD -MP -MF .deps/libparse_a-thriftl.Tpo -c -o libparse_a-thriftl.o `test -f 'thriftl.cc' || echo './'`thriftl.cc g++: error: ./thriftl.cc: No such file or directory g++: fatal error: no input files compilation terminated. Makefile:790: recipe for target 'libparse_a-thriftl.o' failed make[3]: *** [libparse_a-thriftl.o] Error 4 make[3]: Leaving directory '/home/floyd/thrift/compiler/cpp' Makefile:579: recipe for target 'all' failed make[2]: *** [all] Error 2 make[2]: Leaving directory '/home/floyd/thrift/compiler/cpp' Makefile:600: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/home/floyd/thrift' Makefile:521: recipe for target 'all' failed make: *** [all] Error 2 I found the problem is in this command: /bin/bash ../../ylwrap `test -f 'src/thriftl.ll' || echo './'`src/thriftl.ll .c thriftl.cc -- /bin/bash /home/floyd/thrift/missing flex Exactly in second argument to ylwrap which above is just string '.c'. The proper command to run should be: floyd@floyd-VirtualBox:~/thrift$ cd compiler/cpp/ floyd@floyd-VirtualBox:~/thrift/compiler/cpp$ /bin/bash ../../ylwrap `test -f 'src/thriftl.ll' || echo './'`src/thriftl.ll lex.yy.c thriftl.cc -- /bin/bash /home/floyd/thrift/missing flex So instead of '.c' it should have 'lex.yy.c' name which is the default name for lex generated filenames AFAIK. After manually running this command the build continues and even finishes (hurray!). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (THRIFT-320) Common base protocols for text and binary protocols
[ https://issues.apache.org/jira/browse/THRIFT-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James E. King, III updated THRIFT-320: -- Component/s: Wish List Common base protocols for text and binary protocols --- Key: THRIFT-320 URL: https://issues.apache.org/jira/browse/THRIFT-320 Project: Thrift Issue Type: Improvement Components: Wish List Reporter: Bryan Duxbury Priority: Trivial I was thinking that it would be useful to organize our protocols a little bit. What we have today are text protocols like the JSON protocol, and binary protocols like TBinary, TDense, and TCompact. What we could do is make two new abstract protocols, TTextProtocol and TBaseBinaryProtocol, and then inherit protocols from these two appropriately. Text protocols really would only be organizational, at least from my current understanding. Binary protocols, however, can have at least one interesting piece of shared functionality: a 1-byte leading protocol identifier in messages. The primary use of this is to make sure that non-framed binary messages can't be mistaken for framed ones by always making it a negative number. Another benefit of using a protocol identifier is that you could make an auto-negotiating binary protocol implementation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (THRIFT-3099) cmake build is broken on FreeBSD
[
https://issues.apache.org/jira/browse/THRIFT-3099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King, III resolved THRIFT-3099.
Resolution: Fixed
Fix Version/s: 0.9.3
cmake build is broken on FreeBSD
Key: THRIFT-3099
URL: https://issues.apache.org/jira/browse/THRIFT-3099
Project: Thrift
Issue Type: Bug
Components: C glib - Library, Test Suite
Affects Versions: 1.0
Environment: FreeBSD/amd64 10.1-STABLE
C++ compiler: FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032)
20140512
Boost 1.55.0
cmake 3.1.3
Reporter: Marco Molteni
Fix For: 0.9.3
Cmake build is broken on FreeBSD.
Among the problems:
h4. Building the c_glib tests require to specify the Boost include directory
{noformat}
Building CXX object
lib/c_glib/test/CMakeFiles/testgenc_cpp.dir/gen-cpp/ThriftTest.cpp.o
In file included from
/home/marco/src/thrift.marco.hg/thebuild/lib/c_glib/test/gen-cpp/ThriftTest.cpp:7:
In file included from
/home/marco/src/thrift.marco.hg/thebuild/lib/c_glib/test/gen-cpp/ThriftTest.h:10:
In file included from
/home/marco/src/thrift.marco.hg/lib/cpp/src/thrift/TDispatchProcessor.h:22:
In file included from
/home/marco/src/thrift.marco.hg/lib/cpp/src/thrift/TProcessor.h:24:
In file included from
/home/marco/src/thrift.marco.hg/lib/cpp/src/thrift/protocol/TProtocol.h:23:
In file included from
/home/marco/src/thrift.marco.hg/lib/cpp/src/thrift/transport/TTransport.h:23:
/home/marco/src/thrift.marco.hg/lib/cpp/src/thrift/Thrift.h:45:10: fatal
error: 'boost/utility/enable_if.hpp' file not found
#include boost/utility/enable_if.hpp
{noformat}
h4. Compiler complaints about unspecified shared_ptr
- Compiler is confused by shared_ptr, it wants boost::shared_ptr (same
problem for MacOSX, which uses Clang as FreeBSD):
{noformat}
/home/marco/src/thrift.marco.hg/lib/c_glib/test/testthrifttestclient.cpp:594:5:
error: reference to 'shared_ptr' is ambiguous
shared_ptrTProtocolFactory protocolFactory(new
TBinaryProtocolFactory());
^
/usr/include/c++/v1/memory:3750:29: note: candidate found by name lookup is
'std::__1::shared_ptr'
class _LIBCPP_TYPE_VIS_ONLY shared_ptr
^
/usr/local/include/boost/smart_ptr/shared_ptr.hpp:722:36: note: candidate
found by name lookup is 'boost::shared_ptr'
templateclass Y friend class shared_ptr;
{noformat}
h4. libevent and TestClient
{noformat}
Linking CXX executable ../../bin/TestClient
../../lib/libcrosstestgencpp.a(ThriftTest_types.cpp.o): In function
`std::__1::__tree_node_basevoid**
std::__1::__treestd::__1::__value_typethrift::test::Insanity,
...
/home/marco/src/thrift.marco.hg/thebuild/test/cpp/gen-cpp/ThriftTest_types.cpp:
...
undefined reference to
`thrift::test::Insanity::operator(thrift::test::Insanity const) const'
{noformat}
It seems that Clang and gcc (compliers or linkers, haven't investigated) have
a slightly different behavior as below:
On FreeBSD:
{noformat}
codino% for i in lib/*.a; do echo $i; nm --demangle $i | grep
'Insanity::operator'; done
lib/libcrossstressgencpp.a
lib/libcrosstestgencpp.a
U thrift::test::Insanity::operator(thrift::test::Insanity
const) const
lib/liblibparse.a
lib/libtestgenc.a
lib/libtestgenc_cpp.a
U thrift::test::Insanity::operator(thrift::test::Insanity
const) const
lib/libtestgencpp.a
U thrift::test::Insanity::operator(thrift::test::Insanity
const) const
T thrift::test::Insanity::operator(thrift::test::Insanity
const) const
lib/libtestgencpp_cob.a
lib/libthrift.a
lib/libthrift_c_glib.a
lib/libthriftnb.a
lib/libthriftz.a
{noformat}
On Linux:
{noformat}
for i in lib/*.a; do echo $i; nm --demangle $i | grep 'Insanity::operator';
done
lib/libcrossstressgencpp.a
lib/libcrosstestgencpp.a
lib/liblibparse.a
lib/libtestgencpp.a
U thrift::test::Insanity::operator(thrift::test::Insanity
const) const
T thrift::test::Insanity::operator(thrift::test::Insanity
const) const
lib/libtestgencpp_cob.a
lib/libthrift.a
lib/libthriftnb.a
lib/libthriftz.a
{noformat}
Function {{Insanity::operator}} is defined in two indentical files:
{noformat}
lib/cpp/test/ThriftTest_extras.cpp
test/cpp/src/ThriftTest_extras.cpp
{noformat}
Solved by adding {{ThriftTest_extras.cpp}} also to library
{{crosstestgencpp}}. Tested on Linux, no complaints.
Upcoming pull request.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (THRIFT-1542) Create Visual Studio 2010 project files for ASIO based client/server for C++
[ https://issues.apache.org/jira/browse/THRIFT-1542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14597617#comment-14597617 ] James E. King, III commented on THRIFT-1542: Is this issue still outstanding? Create Visual Studio 2010 project files for ASIO based client/server for C++ Key: THRIFT-1542 URL: https://issues.apache.org/jira/browse/THRIFT-1542 Project: Thrift Issue Type: Sub-task Components: C++ - Library Affects Versions: 0.8 Environment: Visual Studio 2010 Reporter: Christian Taedcke Labels: async, vs2010, windows Attachments: THRIFT-1542-against-THRIFT-579_v2.patch To build the asio based c++ client and server, additional Visual Studio 2010 project files have to be provided. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (THRIFT-3190) In perl, a thrift set type should be ordered and have set manipulations
[
https://issues.apache.org/jira/browse/THRIFT-3190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King, III updated THRIFT-3190:
---
Comment: was deleted
(was: I'm used to all sets being ordered because of the amount of work I've
done in C++. It looks like std::set is the only language implementation
mentioned in the link that uses order. The current perl implementation uses a
hash with the key being the set value to guarantee uniqueness which is enough
to satisfy the requirement. Are there are set manipulation operations
available (intersection, union, difference, and symmetric difference) that
operate on a hash configured this way? I would expect if someone is asking for
a set then they expect the ability to use these four fundamental set
manipulations.
)
In perl, a thrift set type should be ordered and have set manipulations
-
Key: THRIFT-3190
URL: https://issues.apache.org/jira/browse/THRIFT-3190
Project: Thrift
Issue Type: Improvement
Components: Perl - Library
Affects Versions: 0.9.2
Reporter: James E. King, III
Priority: Minor
Currently a set type in Thrift equates to a hash where the value of each
type is set to 1. The keys are interpreted as strings and therefore lose
their ordering. The TestClient for cpp sends:
The TestServer for perl (which I am writing to verify SSL server refactoring)
receives:
$thingHASH(0x35da228)={ -1 = '1', -2 = '1', 0 = '1', 1 = '1', 2
= '1' }
Note how -1 and -2 are transposed. Further, there are no set manipulations
available.
Recommend the use of Set::Scalar as a required perl dependency for proper set
operation. This would be a breaking change but necessary to achieve proper
set semantics and operations from the native thrift type.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (THRIFT-3190) In perl, a thrift set type should be ordered and have set manipulations
[
https://issues.apache.org/jira/browse/THRIFT-3190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14598296#comment-14598296
]
James E. King, III commented on THRIFT-3190:
Given the C++ library uses a native set implementation that provides set
manipulations, we should consider using one in other languages as well. As
such, I would still recommend that the perl library use Set::Scalar (or another
implementation providing set manipulations) as the native set type.
In perl, a thrift set type should be ordered and have set manipulations
-
Key: THRIFT-3190
URL: https://issues.apache.org/jira/browse/THRIFT-3190
Project: Thrift
Issue Type: Improvement
Components: Perl - Library
Affects Versions: 0.9.2
Reporter: James E. King, III
Priority: Minor
Currently a set type in Thrift equates to a hash where the value of each
type is set to 1. The keys are interpreted as strings and therefore lose
their ordering. The TestClient for cpp sends:
The TestServer for perl (which I am writing to verify SSL server refactoring)
receives:
$thingHASH(0x35da228)={ -1 = '1', -2 = '1', 0 = '1', 1 = '1', 2
= '1' }
Note how -1 and -2 are transposed. Further, there are no set manipulations
available.
Recommend the use of Set::Scalar as a required perl dependency for proper set
operation. This would be a breaking change but necessary to achieve proper
set semantics and operations from the native thrift type.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (THRIFT-3190) In perl, a thrift set type should use a more proper native implementation
[
https://issues.apache.org/jira/browse/THRIFT-3190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King, III updated THRIFT-3190:
---
Summary: In perl, a thrift set type should use a more proper native
implementation (was: In perl, a thrift set type should be ordered and have
set manipulations)
In perl, a thrift set type should use a more proper native implementation
---
Key: THRIFT-3190
URL: https://issues.apache.org/jira/browse/THRIFT-3190
Project: Thrift
Issue Type: Improvement
Components: Perl - Library
Affects Versions: 0.9.2
Reporter: James E. King, III
Priority: Minor
Currently a set type in Thrift equates to a hash where the value of each
type is set to 1. The keys are interpreted as strings and therefore lose
their ordering. The TestClient for cpp sends:
The TestServer for perl (which I am writing to verify SSL server refactoring)
receives:
$thingHASH(0x35da228)={ -1 = '1', -2 = '1', 0 = '1', 1 = '1', 2
= '1' }
Note how -1 and -2 are transposed. Further, there are no set manipulations
available.
Recommend the use of Set::Scalar as a required perl dependency for proper set
operation. This would be a breaking change but necessary to achieve proper
set semantics and operations from the native thrift type.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (THRIFT-2926) JavaScript: binary protocol implementation
[ https://issues.apache.org/jira/browse/THRIFT-2926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14598907#comment-14598907 ] Randy Abernethy commented on THRIFT-2926: - No updates I know of. If I'm missing a patch newer than the last one I commented on let me know. -Randy JavaScript: binary protocol implementation -- Key: THRIFT-2926 URL: https://issues.apache.org/jira/browse/THRIFT-2926 Project: Thrift Issue Type: Sub-task Components: JavaScript - Library Affects Versions: 0.9.2 Reporter: Radoslaw Gruchalski Assignee: Randy Abernethy Labels: features, javascript I have implemented BinaryProtocol for the JS library. Implementation provided with unit tests. Looking for feedback. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-2926) JavaScript: binary protocol implementation
[ https://issues.apache.org/jira/browse/THRIFT-2926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14598892#comment-14598892 ] Adam Beberg commented on THRIFT-2926: - Any progress on this? JavaScript: binary protocol implementation -- Key: THRIFT-2926 URL: https://issues.apache.org/jira/browse/THRIFT-2926 Project: Thrift Issue Type: Sub-task Components: JavaScript - Library Affects Versions: 0.9.2 Reporter: Radoslaw Gruchalski Assignee: Randy Abernethy Labels: features, javascript I have implemented BinaryProtocol for the JS library. Implementation provided with unit tests. Looking for feedback. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (THRIFT-3191) Perl compiler does not add support for unexpected exception handling
[
https://issues.apache.org/jira/browse/THRIFT-3191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King, III updated THRIFT-3191:
---
Description:
While adding make cross test server support for some other refactoring I
found that the generated code to handle testException exception responses does
not work properly. The test says that the code can die with the specified
exceptions, but it can also die with Thrift::TException.
The generated code that fails in ThriftTest.pm:
{noformat}
sub process_testException {
my ($self, $seqid, $input, $output) = @_;
my $args = new ThriftTest::ThriftTest_testException_args();
$args-read($input);
$input-readMessageEnd();
my $result = new ThriftTest::ThriftTest_testException_result();
eval {
$self-{handler}-testException($args-arg);
}; if( UNIVERSAL::isa($@,'ThriftTest::Xception') ){
$result-{err1} = $@;
}
$output-writeMessageBegin('testException', TMessageType::REPLY, $seqid);
$result-write($output);
$output-writeMessageEnd();
$output-getTransport()-flush();
}
{noformat}
If the resulting implementation dies with a {{new Thrift::TException(foo)}},
the C++ client side gets a void back.
Code that allows the test to pass adds support for capturing TException:
{noformat}
eval {
$self-{handler}-testException($args-arg);
}; if( UNIVERSAL::isa($@,'ThriftTest::Xception') ){
$result-{err1} = $@;
}; if( UNIVERSAL::isa($@,'Thrift::TException') ){
$result-{err1} = $@;
}
}
{noformat}
Adding this to the compiler output is reasonable, however what the generated
code is doing when an exception of another type is thrown seems quite wrong.
It simply ignores the exception and returns an empty reply. I think it would
make more sense here to catch all not-specifically generated exceptions and
make a TException that describes what happened, but let the server continue
processing. This would be a programming error on the server handler
implementation.
We end up with:
{noformat}
eval {
$self-{handler}-testException($args-arg);
}; if( UNIVERSAL::isa($@,'ThriftTest::Xception') ){
$result-{err1} = $@;
} elsif (defined $@) {
$result-{err1} = new Thrift::TException(Unexpected exception: .$@);
}
{noformat}
In addition to this, TException needs to be able to write itself out because it
is not generated, but it doesn't define a write method.
was:
While adding make cross test server support for some other refactoring I
found that the generated code to handle testException exception responses does
not work properly. The test says that the code can die with the specified
exceptions, but it can also die with Thrift::TException.
The generated code that fails in ThriftTest.pm:
{noformat}
sub process_testException {
my ($self, $seqid, $input, $output) = @_;
my $args = new ThriftTest::ThriftTest_testException_args();
$args-read($input);
$input-readMessageEnd();
my $result = new ThriftTest::ThriftTest_testException_result();
eval {
$self-{handler}-testException($args-arg);
}; if( UNIVERSAL::isa($@,'ThriftTest::Xception') ){
$result-{err1} = $@;
}
$output-writeMessageBegin('testException', TMessageType::REPLY, $seqid);
$result-write($output);
$output-writeMessageEnd();
$output-getTransport()-flush();
}
{noformat}
If the resulting implementation dies with a {{new Thrift::TException(foo)}},
the C++ client side gets a void back.
Code that allows the test to pass adds support for capturing TException:
{noformat}
eval {
$self-{handler}-testException($args-arg);
}; if( UNIVERSAL::isa($@,'ThriftTest::Xception') ){
$result-{err1} = $@;
}; if( UNIVERSAL::isa($@,'Thrift::TException') ){
$result-{err1} = $@;
}
}
{noformat}
Adding this to the compiler output is reasonable, however what the generated
code is doing when an exception of another type is thrown seems quite wrong.
It simply ignores the exception and returns an empty reply. I think it would
make more sense here to catch all not-specifically generated exceptions and
make a TException that describes what happened, but let the server continue
processing. This would be a programming error on the server handler
implementation.
We end up with:
{noformat}
eval {
$self-{handler}-testException($args-arg);
}; if( UNIVERSAL::isa($@,'ThriftTest::Xception') ){
$result-{err1} = $@;
} elsif (defined $@) {
$result-{err1} = new Thrift::TException(Unexpected exception: .$@);
}
{noformat}
Perl compiler does not add support for unexpected exception handling
Key: THRIFT-3191
URL: https://issues.apache.org/jira/browse/THRIFT-3191
Project: Thrift
Issue Type: Bug
[jira] [Updated] (THRIFT-3191) Perl compiler does not add support for unexpected exception handling
[
https://issues.apache.org/jira/browse/THRIFT-3191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King, III updated THRIFT-3191:
---
Description:
While adding make cross test server support for some other refactoring I
found that the generated code to handle testException exception responses does
not work properly. The test says that the code can die with the specified
exceptions, but it can also die with Thrift::TException.
The generated code that fails in ThriftTest.pm:
{noformat}
sub process_testException {
my ($self, $seqid, $input, $output) = @_;
my $args = new ThriftTest::ThriftTest_testException_args();
$args-read($input);
$input-readMessageEnd();
my $result = new ThriftTest::ThriftTest_testException_result();
eval {
$self-{handler}-testException($args-arg);
}; if( UNIVERSAL::isa($@,'ThriftTest::Xception') ){
$result-{err1} = $@;
}
$output-writeMessageBegin('testException', TMessageType::REPLY, $seqid);
$result-write($output);
$output-writeMessageEnd();
$output-getTransport()-flush();
}
{noformat}
If the resulting implementation dies with a {{new Thrift::TException(foo)}},
the C++ client side gets a void back.
Code that allows the test to pass adds support for capturing TException:
{noformat}
eval {
$self-{handler}-testException($args-arg);
}; if( UNIVERSAL::isa($@,'ThriftTest::Xception') ){
$result-{err1} = $@;
}; if( UNIVERSAL::isa($@,'Thrift::TException') ){
$result-{err1} = $@;
}
}
{noformat}
Adding this to the compiler output is reasonable, however what the generated
code is doing when an exception of another type is thrown seems quite wrong.
It simply ignores the exception and returns an empty reply. I think it would
make more sense here to catch all not-specifically generated exceptions and
make a TException that describes what happened, but let the server continue
processing. This would be a programming error on the server handler
implementation. Given TException is a base class, we convert this into a
TApplicationException with the code INTERNAL_ERROR.
We end up with:
{noformat}
eval {
$self-{handler}-testException($args-arg);
}; if( UNIVERSAL::isa($@,'ThriftTest::Xception') ){
$result-{err1} = $@;
} elsif (defined $@ and not defined $result-{err1}) {
$result-{err1} = new TApplicationException(Unexpected Exception: .
$@, TApplicationException::INTERNAL_ERROR);
$@ = undef;
}
{noformat}
In addition to this, TException needs to be able to write itself out because it
is not generated, but it doesn't define a write method.
was:
While adding make cross test server support for some other refactoring I
found that the generated code to handle testException exception responses does
not work properly. The test says that the code can die with the specified
exceptions, but it can also die with Thrift::TException.
The generated code that fails in ThriftTest.pm:
{noformat}
sub process_testException {
my ($self, $seqid, $input, $output) = @_;
my $args = new ThriftTest::ThriftTest_testException_args();
$args-read($input);
$input-readMessageEnd();
my $result = new ThriftTest::ThriftTest_testException_result();
eval {
$self-{handler}-testException($args-arg);
}; if( UNIVERSAL::isa($@,'ThriftTest::Xception') ){
$result-{err1} = $@;
}
$output-writeMessageBegin('testException', TMessageType::REPLY, $seqid);
$result-write($output);
$output-writeMessageEnd();
$output-getTransport()-flush();
}
{noformat}
If the resulting implementation dies with a {{new Thrift::TException(foo)}},
the C++ client side gets a void back.
Code that allows the test to pass adds support for capturing TException:
{noformat}
eval {
$self-{handler}-testException($args-arg);
}; if( UNIVERSAL::isa($@,'ThriftTest::Xception') ){
$result-{err1} = $@;
}; if( UNIVERSAL::isa($@,'Thrift::TException') ){
$result-{err1} = $@;
}
}
{noformat}
Adding this to the compiler output is reasonable, however what the generated
code is doing when an exception of another type is thrown seems quite wrong.
It simply ignores the exception and returns an empty reply. I think it would
make more sense here to catch all not-specifically generated exceptions and
make a TException that describes what happened, but let the server continue
processing. This would be a programming error on the server handler
implementation.
We end up with:
{noformat}
eval {
$self-{handler}-testException($args-arg);
}; if( UNIVERSAL::isa($@,'ThriftTest::Xception') ){
$result-{err1} = $@;
} elsif (defined $@) {
$result-{err1} = new Thrift::TException(Unexpected exception: .$@);
}
{noformat}
In addition to this, TException needs to be able to write itself out because it
is not generated, but it doesn't
[jira] [Updated] (THRIFT-3191) Perl compiler does not add support for unexpected exception handling
[
https://issues.apache.org/jira/browse/THRIFT-3191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King, III updated THRIFT-3191:
---
Description:
While adding make cross test server support for some other refactoring I
found that the generated code to handle testException exception responses does
not work properly. The test says that the code can die with the specified
exceptions, but it can also die with Thrift::TException.
The generated code that fails in ThriftTest.pm:
{noformat}
sub process_testException {
my ($self, $seqid, $input, $output) = @_;
my $args = new ThriftTest::ThriftTest_testException_args();
$args-read($input);
$input-readMessageEnd();
my $result = new ThriftTest::ThriftTest_testException_result();
eval {
$self-{handler}-testException($args-arg);
}; if( UNIVERSAL::isa($@,'ThriftTest::Xception') ){
$result-{err1} = $@;
}
$output-writeMessageBegin('testException', TMessageType::REPLY, $seqid);
$result-write($output);
$output-writeMessageEnd();
$output-getTransport()-flush();
}
{noformat}
If the resulting implementation dies with a {{new Thrift::TException(foo)}},
the C++ client side gets a void back.
Code that allows the test to pass adds support for capturing TException:
{noformat}
eval {
$self-{handler}-testException($args-arg);
}; if( UNIVERSAL::isa($@,'ThriftTest::Xception') ){
$result-{err1} = $@;
}; if( UNIVERSAL::isa($@,'Thrift::TException') ){
$result-{err1} = $@;
}
}
{noformat}
Adding this to the compiler output is reasonable, however what the generated
code is doing when an exception of another type is thrown seems quite wrong.
It simply ignores the exception and returns an empty reply. I think it would
make more sense here to catch all not-specifically generated exceptions and
make a TException that describes what happened, but let the server continue
processing. This would be a programming error on the server handler
implementation. Given TException is a base class, we convert this into a
TApplicationException with the code INTERNAL_ERROR.
We end up with:
{noformat}
eval {
$self-{handler}-testException($args-arg);
}; if( UNIVERSAL::isa($@,'ThriftTest::Xception') ){
$result-{err1} = $@;
} elsif (defined $@ and not defined $result-{err1}) {
$result-{err1} = new TApplicationException(Unexpected Exception: .
$@, TApplicationException::INTERNAL_ERROR);
$@ = undef;
}
{noformat}
was:
While adding make cross test server support for some other refactoring I
found that the generated code to handle testException exception responses does
not work properly. The test says that the code can die with the specified
exceptions, but it can also die with Thrift::TException.
The generated code that fails in ThriftTest.pm:
{noformat}
sub process_testException {
my ($self, $seqid, $input, $output) = @_;
my $args = new ThriftTest::ThriftTest_testException_args();
$args-read($input);
$input-readMessageEnd();
my $result = new ThriftTest::ThriftTest_testException_result();
eval {
$self-{handler}-testException($args-arg);
}; if( UNIVERSAL::isa($@,'ThriftTest::Xception') ){
$result-{err1} = $@;
}
$output-writeMessageBegin('testException', TMessageType::REPLY, $seqid);
$result-write($output);
$output-writeMessageEnd();
$output-getTransport()-flush();
}
{noformat}
If the resulting implementation dies with a {{new Thrift::TException(foo)}},
the C++ client side gets a void back.
Code that allows the test to pass adds support for capturing TException:
{noformat}
eval {
$self-{handler}-testException($args-arg);
}; if( UNIVERSAL::isa($@,'ThriftTest::Xception') ){
$result-{err1} = $@;
}; if( UNIVERSAL::isa($@,'Thrift::TException') ){
$result-{err1} = $@;
}
}
{noformat}
Adding this to the compiler output is reasonable, however what the generated
code is doing when an exception of another type is thrown seems quite wrong.
It simply ignores the exception and returns an empty reply. I think it would
make more sense here to catch all not-specifically generated exceptions and
make a TException that describes what happened, but let the server continue
processing. This would be a programming error on the server handler
implementation. Given TException is a base class, we convert this into a
TApplicationException with the code INTERNAL_ERROR.
We end up with:
{noformat}
eval {
$self-{handler}-testException($args-arg);
}; if( UNIVERSAL::isa($@,'ThriftTest::Xception') ){
$result-{err1} = $@;
} elsif (defined $@ and not defined $result-{err1}) {
$result-{err1} = new TApplicationException(Unexpected Exception: .
$@, TApplicationException::INTERNAL_ERROR);
$@ = undef;
}
{noformat}
In addition to this, TException needs to be able
[jira] [Updated] (THRIFT-3185) typedef is ignored in d.ts files for TypeScript.
[
https://issues.apache.org/jira/browse/THRIFT-3185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James E. King, III updated THRIFT-3185:
---
Affects Version/s: 0.9.2
typedef is ignored in d.ts files for TypeScript.
Key: THRIFT-3185
URL: https://issues.apache.org/jira/browse/THRIFT-3185
Project: Thrift
Issue Type: Improvement
Components: JavaScript - Compiler
Affects Versions: 0.9.2
Reporter: HIRANO Satoshi
TypeScript support is very valuable for us.
But, currently d.ts files for TypeScript does not include any info on
typedefs defined in IDLs.
For example, we have foo.idl like this.
typedef string userID
struct Foo {1: userID s }
Currently this is compiled into foo.d.ts like this.
declare class Foo { s: string; }
I should be like this, or we have to use string instead of meaningfull userID.
declare type userID = string;
declare class Foo { s: userID; }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (THRIFT-2922) $TRIAL is used with Python tests but not tested accordingly
[
https://issues.apache.org/jira/browse/THRIFT-2922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14598728#comment-14598728
]
Jake Farrell commented on THRIFT-2922:
--
[~jensg] your patch was close, needed to check for the TRIAL apps existence and
then either enable or disable has_python since its required for the py.twisted
unit tests. With new patch get
{code}
/usr/bin/trial ./test_suite.py
test_suite
ThriftTestCase
testByte ... [OK]
testDouble ... [OK]
testException ... [OK]
testI32 ...[OK]
testI64 ...[OK]
testOneway ... [OK]
testString ... [OK]
testStruct ... [OK]
testVoid ... [OK]
---
Ran 9 tests in 1.048s
PASSED (successes=9)
{code}
$TRIAL is used with Python tests but not tested accordingly
---
Key: THRIFT-2922
URL: https://issues.apache.org/jira/browse/THRIFT-2922
Project: Thrift
Issue Type: Bug
Components: Python - Library
Reporter: Jens Geyer
Priority: Minor
Fix For: 0.9.3
Attachments:
THRIFT-2922_TRIAL-is-required-for-py.Twisted-tests-but-not-fully.patch
I did not install trial at first, not knowing that I'm going to need it. The
twisted test does not check whether $TRIAL actually has been found by
configure, it simply tries to call an empty command then, leading to a funny
error message about the first argument not being executable.
The workaround is to simply install trial.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (THRIFT-2922) $TRIAL is used with Python tests but not tested accordingly
[ https://issues.apache.org/jira/browse/THRIFT-2922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jake Farrell closed THRIFT-2922. Resolution: Fixed Fix Version/s: 0.9.3 Assignee: Jake Farrell $TRIAL is used with Python tests but not tested accordingly --- Key: THRIFT-2922 URL: https://issues.apache.org/jira/browse/THRIFT-2922 Project: Thrift Issue Type: Bug Components: Python - Library Reporter: Jens Geyer Assignee: Jake Farrell Priority: Minor Fix For: 0.9.3 Attachments: THRIFT-2922_TRIAL-is-required-for-py.Twisted-tests-but-not-fully.patch I did not install trial at first, not knowing that I'm going to need it. The twisted test does not check whether $TRIAL actually has been found by configure, it simply tries to call an empty command then, leading to a funny error message about the first argument not being executable. The workaround is to simply install trial. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (THRIFT-2922) $TRIAL is used with Python tests but not tested accordingly
[ https://issues.apache.org/jira/browse/THRIFT-2922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14598753#comment-14598753 ] Hudson commented on THRIFT-2922: SUCCESS: Integrated in Thrift #1579 (See [https://builds.apache.org/job/Thrift/1579/]) Thrift-2922: TRIAL is used with Python tests but not tested accordingly (jfarrell: rev 6cdbd98b717b9f2b720ce7dc2899fbada94876f9) * test/py.twisted/Makefile.am * configure.ac * test/py.twisted/test_suite.py $TRIAL is used with Python tests but not tested accordingly --- Key: THRIFT-2922 URL: https://issues.apache.org/jira/browse/THRIFT-2922 Project: Thrift Issue Type: Bug Components: Python - Library Reporter: Jens Geyer Assignee: Jake Farrell Priority: Minor Fix For: 0.9.3 Attachments: THRIFT-2922_TRIAL-is-required-for-py.Twisted-tests-but-not-fully.patch I did not install trial at first, not knowing that I'm going to need it. The twisted test does not check whether $TRIAL actually has been found by configure, it simply tries to call an empty command then, leading to a funny error message about the first argument not being executable. The workaround is to simply install trial. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] thrift pull request: Thrift-1857: Python 3 support, redux
Github user jfarrell commented on the pull request: https://github.com/apache/thrift/pull/213#issuecomment-114706805 @c4urself working on the next RC now, if we can get all the changes in this patch and the comments from @jeroenvlek into one patch updated against trunk and passing tests then happy to get it in --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (THRIFT-3042) Dockerfiles fail to build
[
https://issues.apache.org/jira/browse/THRIFT-3042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14598768#comment-14598768
]
Jake Farrell commented on THRIFT-3042:
--
cmake currently failing tests in updated dockerfiles
{code}
The following tests FAILED:
19 - processor_test (Failed)
36 - python_test (Failed)
Errors while running CTest
make[3]: *** [CMakeFiles/check] Error 8
make[2]: *** [CMakeFiles/check.dir/all] Error 2
make[1]: *** [CMakeFiles/check.dir/rule] Error 2
make: *** [check] Error 2
{code}
Dockerfiles fail to build
-
Key: THRIFT-3042
URL: https://issues.apache.org/jira/browse/THRIFT-3042
Project: Thrift
Issue Type: Bug
Components: Build Process
Affects Versions: 0.9.3
Environment: ubuntu 14.04 docker host
Reporter: Randy Abernethy
Assignee: Jake Farrell
Priority: Minor
Attachments: thrift-3042-ubuntu.patch
h3. Docker build on build/docker/ubuntu/Dockerfile fails on Haxe setup. e.g.
docker@ubuntu:~$ docker build -t thrift thrift/build/docker/ubuntu
...
haxe-3.1.3/std/Xml.hx
Uncaught exception - load.c(237) : Failed to load library : std.ndll
(std.ndll: cannot open shared object file: No such file or directory)
INFO[0011] The command [/bin/sh -c apt-get install -y libneko0 mkdir
-p /tmp/haxe /usr/lib/haxe curl
http://haxe.org/website-content/downloads/3,1,3/downloads/haxe-3.1.3-linux64.tar.gz
-o /tmp/haxe/haxe-3.1.3-linux64.tar.gz tar -xvzf
/tmp/haxe/haxe-3.1.3-linux64.tar.gz -C /usr/lib/haxe --strip-components=1
ln -s /usr/lib/haxe/haxe /usr/bin/haxe ln -s /usr/lib/haxe/haxelib
/usr/bin/haxelib ln -s /usr/lib/libneko.so.0 /usr/lib/libneko.so
mkdir -p /usr/lib/haxe/lib chmod -R 777 /usr/lib/haxe/lib
haxelib setup /usr/lib/haxe/lib haxelib install hxcpp] returned a
non-zero code: 1
h3. Docker build on build/docker/centosDockerfile fails on Boost build. e.g.
docker@ubuntu:~$ docker build -t thrift thrift/build/docker/centos
...
/tmp/boost/boost_1_55_0/tools/build/v2/tools/gcc.jam:148: in gcc.init from
module gcc
error: toolset gcc initialization:
error: no command provided, default command 'g++' not found
error: initialized from project-config.jam:12
/tmp/boost/boost_1_55_0/tools/build/v2/build/toolset.jam:41: in toolset.using
from module toolset
/tmp/boost/boost_1_55_0/tools/build/v2/build/project.jam:1007: in using from
module project-rules
project-config.jam:12: in modules.load from module project-config
/tmp/boost/boost_1_55_0/tools/build/v2/build-system.jam:249: in load-config
from module build-system
/tmp/boost/boost_1_55_0/tools/build/v2/build-system.jam:412: in
load-configuration-files from module build-system
/tmp/boost/boost_1_55_0/tools/build/v2/build-system.jam:524: in load from
module build-system
/tmp/boost/boost_1_55_0/tools/build/v2/kernel/modules.jam:289: in import from
module modules
/tmp/boost/boost_1_55_0/tools/build/v2/kernel/bootstrap.jam:139: in
boost-build from module
/tmp/boost/boost_1_55_0/boost-build.jam:17: in module scope from module
INFO[0264] The command [/bin/sh -c mkdir -p /tmp/boost curl -SL
http://sourceforge.net/projects/boost/files/boost/1.55.0/boost_1_55_0.tar.gz;
| tar -xzC /tmp/boost cd /tmp/boost/boost_1_55_0
./bootstrap.sh ./b2 install cd $HOME] returned a non-zero
code: 1
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (THRIFT-3185) typedef is ignored in d.ts files for TypeScript.
[
https://issues.apache.org/jira/browse/THRIFT-3185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14598564#comment-14598564
]
HIRANO Satoshi commented on THRIFT-3185:
Hi,
compiler/cpp/src/generate/t_js_generator.cc
hirano
typedef is ignored in d.ts files for TypeScript.
Key: THRIFT-3185
URL: https://issues.apache.org/jira/browse/THRIFT-3185
Project: Thrift
Issue Type: Improvement
Reporter: HIRANO Satoshi
TypeScript support is very valuable for us.
But, currently d.ts files for TypeScript does not include any info on
typedefs defined in IDLs.
For example, we have foo.idl like this.
typedef string userID
struct Foo {1: userID s }
Currently this is compiled into foo.d.ts like this.
declare class Foo { s: string; }
I should be like this, or we have to use string instead of meaningfull userID.
declare type userID = string;
declare class Foo { s: userID; }
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (THRIFT-3199) Exception field has basic metadata
Laurent Goujon created THRIFT-3199: -- Summary: Exception field has basic metadata Key: THRIFT-3199 URL: https://issues.apache.org/jira/browse/THRIFT-3199 Project: Thrift Issue Type: Bug Reporter: Laurent Goujon If a field of a struct or of an union, or the type of a container is an exception, the metadata associated with the field says it's a struct, but the value is FieldValueMetaData, not StructMetaData. As a consequence, it is not possible to get the class for the field. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
