[jira] [Commented] (THRIFT-3362) make check fails for C++

2015-09-30 Thread Jens Geyer (JIRA)

[ 
https://issues.apache.org/jira/browse/THRIFT-3362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14938338#comment-14938338
 ] 

Jens Geyer commented on THRIFT-3362:


1) make without {{-j}}: yes of course
2) cmake: not tested yet 
3) strace: yes, while the UnitTest ends successfully, with "no errors" and 0, 
the SecurityTest ends with this:

{code}
close(3)= 0
open("/proc/1/stat", O_RDONLY)  = 3
read(3, "1 (systemd) S 0 1 1 0 -1 4219136"..., 500) = 199
readlink("/proc/1/exe", 0xbffe4f79, 500) = -1 EACCES (Permission denied)
close(3)= 0
rt_sigaction(SIGILL, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGILL, {0x8095870, [], SA_STACK|SA_SIGINFO}, {SIG_DFL, [], 0}, 8) 
= 0
rt_sigaction(SIGFPE, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGFPE, {0x8095870, [], SA_STACK|SA_SIGINFO}, {SIG_DFL, [], 0}, 8) 
= 0
rt_sigaction(SIGSEGV, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGSEGV, {0x8095870, [], SA_STACK|SA_SIGINFO}, {SIG_DFL, [], 0}, 
8) = 0
rt_sigaction(SIGBUS, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGBUS, {0x8095870, [], SA_STACK|SA_SIGINFO}, {SIG_DFL, [], 0}, 8) 
= 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGCHLD, {0x8095870, [], SA_STACK|SA_SIGINFO}, {SIG_DFL, [], 0}, 
8) = 0
rt_sigaction(SIGIO, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGIO, {0x8095870, [], SA_STACK|SA_SIGINFO}, {SIG_DFL, [], 0}, 8) 
= 0
rt_sigaction(SIGABRT, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGABRT, {0x8095870, [], SA_STACK|SA_SIGINFO}, {SIG_DFL, [], 0}, 
8) = 0
sigaltstack(NULL, {ss_sp=0, ss_flags=SS_DISABLE, ss_size=0}) = 0
sigaltstack({ss_sp=0x97df040, ss_flags=0, ss_size=8192}, NULL) = 0
rt_sigprocmask(SIG_BLOCK, NULL, [], 8)  = 0
mmap2(NULL, 8392704, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, 
-1, 0) = 0xb6898000
mprotect(0xb6898000, 4096, PROT_NONE)   = 0
clone(child_stack=0xb7098424, 
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
 parent_tidptr=0xb7098ba8, {entry_number:6, base_addr:0xb7098b40, 
limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, 
seg_not_present:0, useable:1}, child_tidptr=0xb7098ba8) = 17606
futex(0xbffe4740, FUTEX_WAIT_PRIVATE, 1, NULL) = 0
futex(0xbffe4724, FUTEX_WAIT_PRIVATE, 2, NULL) = 0
futex(0xbffe4724, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0xbffe470c, FUTEX_WAIT_PRIVATE, 2, NULL) = 0
futex(0xbffe470c, FUTEX_WAKE_PRIVATE, 1) = 0
mmap2(NULL, 8392704, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, 
-1, 0) = 0xb5eff000
mprotect(0xb5eff000, 4096, PROT_NONE)   = 0
clone(child_stack=0xb66ff424, 
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
 parent_tidptr=0xb66ffba8, {entry_number:6, base_addr:0xb66ffb40, 
limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, 
seg_not_present:0, useable:1}, child_tidptr=0xb66ffba8) = 17607
futex(0x97cecbc, FUTEX_WAIT_PRIVATE, 1, NULL 
+++ killed by SIGPIPE +++
{code}

But what does that tell me?


> make check fails for C++
> 
>
> Key: THRIFT-3362
> URL: https://issues.apache.org/jira/browse/THRIFT-3362
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library, Test Suite
> Environment: openSUSE
>Reporter: Jens Geyer
>
> When I run "make check" inside {{lib/cpp}} I get this error:
> {code}
> FAIL: SecurityTest
> {code}
> No more information besides that, and all other tests succeed. When I run 
> the SecurityTest test alone, it succeeds - it fails only with make check. I 
> have no idea why, and I can't get the test routine to print more log info to 
> the console with make check. I already tried adding --log_level 
> and --report_level to no avail, again this works well when run standalone.
> I'm a bit stuck here. Maybe the problem lies in my setup, but I have no idea 
> what to look for. Any helpful advice would be really great.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (THRIFT-2630) windows7 64bit pc. ipv4 and ipv6 pc.can't use

2015-09-30 Thread James E. King, III (JIRA)

 [ 
https://issues.apache.org/jira/browse/THRIFT-2630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James E. King, III resolved THRIFT-2630.

   Resolution: Duplicate
Fix Version/s: (was: 1.0)
   0.9.2

The winsock initialization was added since this was posted as part of 
THRIFT-2442.

The documentation for getaddrinfo from Microsoft states that =PF_UNSPEC is the 
correct value to support either IPv4 or IPv6.  As such, there is nothing else 
to do for this ticket, so I am resolving it as a duplicate of THRIFT-2442.

> windows7 64bit pc. ipv4 and ipv6 pc.can't use
> -
>
> Key: THRIFT-2630
> URL: https://issues.apache.org/jira/browse/THRIFT-2630
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
>Affects Versions: 0.9.1
> Environment: windows7 64bit pc. ipv4 and ipv6 pc.can't use
>Reporter: alan
>Assignee: James E. King, III
> Fix For: 0.9.2
>
> Attachments: TServerSocket.cpp
>
>
> net error no : 10093



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (THRIFT-3322) CMake generated "make check" failes on python_test

2015-09-30 Thread Roger Meier (JIRA)

 [ 
https://issues.apache.org/jira/browse/THRIFT-3322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roger Meier resolved THRIFT-3322.
-
Resolution: Fixed
  Assignee: Roger Meier

committed

> CMake generated "make check" failes on python_test
> --
>
> Key: THRIFT-3322
> URL: https://issues.apache.org/jira/browse/THRIFT-3322
> Project: Thrift
>  Issue Type: Bug
>  Components: Python - Library
>Affects Versions: 0.9.2
>Reporter: Claudius Heine
>Assignee: Roger Meier
>Priority: Minor
> Attachments: 
> 0001-THRIFT-3322-Fix-python_test-when-generated-via-cmake.patch
>
>
> The "python_test" case failes on the cmake generated test suite called via 
> "make check" or "ctest -R python_test".
> Reason for this is that the code for the python types are not generated via 
> the thrift compiler.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (THRIFT-2342) Add __FILE__ and __LINE__ to Thrift C++ excpetions

2015-09-30 Thread Roger Meier (JIRA)

[ 
https://issues.apache.org/jira/browse/THRIFT-2342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14936471#comment-14936471
 ] 

Roger Meier commented on THRIFT-2342:
-

There was never the idea to send this over the wire from my side. This is 
something to be logged locally.
But I agree with booth of you on being more specific with INVALID_DATA.


> Add __FILE__ and __LINE__ to Thrift C++ excpetions
> --
>
> Key: THRIFT-2342
> URL: https://issues.apache.org/jira/browse/THRIFT-2342
> Project: Thrift
>  Issue Type: Improvement
>  Components: C++ - Compiler, C++ - Library
>Reporter: George Godik
>Priority: Minor
>  Labels: newbie
>
> Thrift exceptions are somewhat difficult to trace from debug logs. I'd like 
> to add __FILE__AND__LINE__ as a second parameter to some exceptions to make 
> them easier to find.
> For example:
> Every time a required field is not set, the exception that gets generated is 
> a very generic
> throw TProtocolException(TProtocolException::INVALID_DATA)
> see - 
> https://git-wip-us.apache.org/repos/asf?p=thrift.git;a=blob;f=compiler/cpp/src/generate/t_cpp_generator.cc;h=298096d3265baa1f008501eb7c26bb4ae96ffa4b;hb=HEAD#l1372
> I think I'll start with patching up TProtocolExcpetion in the compiler and if 
> people like this I can make a separate issue and patch for other exceptions



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (THRIFT-3362) make check fails for C++

2015-09-30 Thread Roger Meier (JIRA)

[ 
https://issues.apache.org/jira/browse/THRIFT-3362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14938889#comment-14938889
 ] 

Roger Meier commented on THRIFT-3362:
-

this might give a hint
{noformat}
open("/proc/1/stat", O_RDONLY)  = 3
read(3, "1 (systemd) S 0 1 1 0 -1 4219136"..., 500) = 199
readlink("/proc/1/exe", 0xbffe4f79, 500) = -1 EACCES (Permission denied)
{noformat}

does systemd play on the same party as we do?
{noformat}
lib/cpp/test/TestPortFixture.h:m_serverPort = (spEnv) ? atoi(spEnv) : 9090;
{noformat}

using TEST_PORT might be an option here

> make check fails for C++
> 
>
> Key: THRIFT-3362
> URL: https://issues.apache.org/jira/browse/THRIFT-3362
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library, Test Suite
> Environment: openSUSE
>Reporter: Jens Geyer
>
> When I run "make check" inside {{lib/cpp}} I get this error:
> {code}
> FAIL: SecurityTest
> {code}
> No more information besides that, and all other tests succeed. When I run 
> the SecurityTest test alone, it succeeds - it fails only with make check. I 
> have no idea why, and I can't get the test routine to print more log info to 
> the console with make check. I already tried adding --log_level 
> and --report_level to no avail, again this works well when run standalone.
> I'm a bit stuck here. Maybe the problem lies in my setup, but I have no idea 
> what to look for. Any helpful advice would be really great.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (THRIFT-2630) windows7 64bit pc. ipv4 and ipv6 pc.can't use

2015-09-30 Thread Jake Farrell (JIRA)

 [ 
https://issues.apache.org/jira/browse/THRIFT-2630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jake Farrell updated THRIFT-2630:
-
Fix Version/s: (was: 0.9.2)
   0.9.3

> windows7 64bit pc. ipv4 and ipv6 pc.can't use
> -
>
> Key: THRIFT-2630
> URL: https://issues.apache.org/jira/browse/THRIFT-2630
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
>Affects Versions: 0.9.1
> Environment: windows7 64bit pc. ipv4 and ipv6 pc.can't use
>Reporter: alan
>Assignee: James E. King, III
> Fix For: 0.9.3
>
> Attachments: TServerSocket.cpp
>
>
> net error no : 10093



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (THRIFT-3359) Binary field incompatibilities

2015-09-30 Thread Jake Farrell (JIRA)

 [ 
https://issues.apache.org/jira/browse/THRIFT-3359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jake Farrell updated THRIFT-3359:
-
Fix Version/s: (was: 0.9.4)

> Binary field incompatibilities
> --
>
> Key: THRIFT-3359
> URL: https://issues.apache.org/jira/browse/THRIFT-3359
> Project: Thrift
>  Issue Type: Bug
>  Components: C# - Library, C++ - Library, Java - Library, JavaScript 
> - Library, Node.js - Library, Python - Library
>Affects Versions: 0.9.3
>Reporter: Nobuaki Sukegawa
>Assignee: Nobuaki Sukegawa
>
> Binary fields in TJSONProtocols of many languages are incompatible to each 
> other.
> Also, those in all protocols of NodeJS cannot reliably talk to other 
> languages.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (THRIFT-2630) windows7 64bit pc. ipv4 and ipv6 pc.can't use

2015-09-30 Thread James E. King, III (JIRA)

[ 
https://issues.apache.org/jira/browse/THRIFT-2630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14938820#comment-14938820
 ] 

James E. King, III commented on THRIFT-2630:


It was actually fixed in 0.9.2, but if you want to put it into any release 
notes for 0.9.3, I assume that's why you changed it?

> windows7 64bit pc. ipv4 and ipv6 pc.can't use
> -
>
> Key: THRIFT-2630
> URL: https://issues.apache.org/jira/browse/THRIFT-2630
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
>Affects Versions: 0.9.1
> Environment: windows7 64bit pc. ipv4 and ipv6 pc.can't use
>Reporter: alan
>Assignee: James E. King, III
> Fix For: 0.9.3
>
> Attachments: TServerSocket.cpp
>
>
> net error no : 10093



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (THRIFT-3362) make check fails for C++

2015-09-30 Thread Roger Meier (JIRA)

[ 
https://issues.apache.org/jira/browse/THRIFT-3362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14936741#comment-14936741
 ] 

Roger Meier edited comment on THRIFT-3362 at 9/30/15 11:43 AM:
---

Do you run make without {noformat}-j{noformat} ?
Does the test pass when using cmake?
Does {noformat}strace ./SecurityTest{noformat} and {noformat}strace 
./UnitTests{noformat}
provide different results?


was (Author: roger.meier):
Do you run make without {noformat}-j{noformat} ?
Does the test mass when using cmake?
Does {noformat}strace ./SecurityTest{noformat} and {noformat}strace 
./UnitTests{noformat}
provide different results?

> make check fails for C++
> 
>
> Key: THRIFT-3362
> URL: https://issues.apache.org/jira/browse/THRIFT-3362
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library, Test Suite
> Environment: openSUSE
>Reporter: Jens Geyer
>
> When I run "make check" inside {{lib/cpp}} I get this error:
> {code}
> FAIL: SecurityTest
> {code}
> No more information besides that, and all other tests succeed. When I run 
> the SecurityTest test alone, it succeeds - it fails only with make check. I 
> have no idea why, and I can't get the test routine to print more log info to 
> the console with make check. I already tried adding --log_level 
> and --report_level to no avail, again this works well when run standalone.
> I'm a bit stuck here. Maybe the problem lies in my setup, but I have no idea 
> what to look for. Any helpful advice would be really great.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (THRIFT-3362) make check fails for C++

2015-09-30 Thread Roger Meier (JIRA)

[ 
https://issues.apache.org/jira/browse/THRIFT-3362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14936741#comment-14936741
 ] 

Roger Meier commented on THRIFT-3362:
-

Do you run make without {noformat}-j{noformat} ?
Does the test mass when using cmake?
Does {noformat}strace ./SecurityTest{noformat} and {noformat}strace 
./UnitTests{noformat}
provide different results?

> make check fails for C++
> 
>
> Key: THRIFT-3362
> URL: https://issues.apache.org/jira/browse/THRIFT-3362
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library, Test Suite
> Environment: openSUSE
>Reporter: Jens Geyer
>
> When I run "make check" inside {{lib/cpp}} I get this error:
> {code}
> FAIL: SecurityTest
> {code}
> No more information besides that, and all other tests succeed. When I run 
> the SecurityTest test alone, it succeeds - it fails only with make check. I 
> have no idea why, and I can't get the test routine to print more log info to 
> the console with make check. I already tried adding --log_level 
> and --report_level to no avail, again this works well when run standalone.
> I'm a bit stuck here. Maybe the problem lies in my setup, but I have no idea 
> what to look for. Any helpful advice would be really great.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (THRIFT-3322) CMake generated "make check" failes on python_test

2015-09-30 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/THRIFT-3322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14936724#comment-14936724
 ] 

Hudson commented on THRIFT-3322:


SUCCESS: Integrated in Thrift #1671 (See 
[https://builds.apache.org/job/Thrift/1671/])
THRIFT-3322 CMake generated "make check" failes on python_test (roger: rev 
a03464c526931fd09fc89a6e952600d0c5514421)
* test/py/generate.cmake
* test/py/CMakeLists.txt


> CMake generated "make check" failes on python_test
> --
>
> Key: THRIFT-3322
> URL: https://issues.apache.org/jira/browse/THRIFT-3322
> Project: Thrift
>  Issue Type: Bug
>  Components: Python - Library
>Affects Versions: 0.9.2
>Reporter: Claudius Heine
>Assignee: Roger Meier
>Priority: Minor
> Attachments: 
> 0001-THRIFT-3322-Fix-python_test-when-generated-via-cmake.patch
>
>
> The "python_test" case failes on the cmake generated test suite called via 
> "make check" or "ctest -R python_test".
> Reason for this is that the code for the python types are not generated via 
> the thrift compiler.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (THRIFT-3363) Reporting a missing required field (TProtocolException::INVALID_DATA) to the client is not informative enough

2015-09-30 Thread James E. King, III (JIRA)

 [ 
https://issues.apache.org/jira/browse/THRIFT-3363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James E. King, III updated THRIFT-3363:
---
Affects Version/s: 0.9.3
   0.8
   0.9
   0.9.1
   0.9.2

> Reporting a missing required field (TProtocolException::INVALID_DATA) to the 
> client is not informative enough
> -
>
> Key: THRIFT-3363
> URL: https://issues.apache.org/jira/browse/THRIFT-3363
> Project: Thrift
>  Issue Type: Improvement
>  Components: C++ - Compiler, C++ - Library
>Affects Versions: 0.8, 0.9, 0.9.1, 0.9.2, 0.9.3
>Reporter: James E. King, III
>Assignee: James E. King, III
>Priority: Minor
>
> This may affect all languages, however it was initially reported against C++ 
> by [~ggodik] in THRIFT-2342:
> Every time a required field is not set, the exception that gets generated is 
> a very generic:
> {{throw TProtocolException(TProtocolException::INVALID_DATA);}}
> (see - 
> https://git-wip-us.apache.org/repos/asf?p=thrift.git;a=blob;f=compiler/cpp/src/generate/t_cpp_generator.cc;h=298096d3265baa1f008501eb7c26bb4ae96ffa4b;hb=HEAD#l1372)
> It would be useful to indicate the invalid data field in this exception case.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (THRIFT-3363) Reporting a missing required field (TProtocolException::INVALID_DATA) to the client is not informative enough

2015-09-30 Thread James E. King, III (JIRA)

 [ 
https://issues.apache.org/jira/browse/THRIFT-3363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James E. King, III updated THRIFT-3363:
---
Summary: Reporting a missing required field 
(TProtocolException::INVALID_DATA) to the client is not informative enough  
(was: Reporting a missing required field to the client is not informative 
enough)

> Reporting a missing required field (TProtocolException::INVALID_DATA) to the 
> client is not informative enough
> -
>
> Key: THRIFT-3363
> URL: https://issues.apache.org/jira/browse/THRIFT-3363
> Project: Thrift
>  Issue Type: Improvement
>  Components: C++ - Compiler, C++ - Library
>Affects Versions: 0.8, 0.9, 0.9.1, 0.9.2, 0.9.3
>Reporter: James E. King, III
>Assignee: James E. King, III
>Priority: Minor
>
> This may affect all languages, however it was initially reported against C++ 
> by [~ggodik] in THRIFT-2342:
> Every time a required field is not set, the exception that gets generated is 
> a very generic:
> {{throw TProtocolException(TProtocolException::INVALID_DATA);}}
> (see - 
> https://git-wip-us.apache.org/repos/asf?p=thrift.git;a=blob;f=compiler/cpp/src/generate/t_cpp_generator.cc;h=298096d3265baa1f008501eb7c26bb4ae96ffa4b;hb=HEAD#l1372)
> It would be useful to indicate the invalid data field in this exception case.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (THRIFT-3363) Reporting a missing required field (TProtocolException::INVALID_DATA) to the client is not informative enough

2015-09-30 Thread James E. King, III (JIRA)

 [ 
https://issues.apache.org/jira/browse/THRIFT-3363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James E. King, III updated THRIFT-3363:
---
Labels:   (was: newbie)

> Reporting a missing required field (TProtocolException::INVALID_DATA) to the 
> client is not informative enough
> -
>
> Key: THRIFT-3363
> URL: https://issues.apache.org/jira/browse/THRIFT-3363
> Project: Thrift
>  Issue Type: Improvement
>  Components: C++ - Compiler, C++ - Library
>Affects Versions: 0.8, 0.9, 0.9.1, 0.9.2, 0.9.3
>Reporter: James E. King, III
>Assignee: James E. King, III
>Priority: Minor
>
> This may affect all languages, however it was initially reported against C++ 
> by [~ggodik] in THRIFT-2342:
> Every time a required field is not set, the exception that gets generated is 
> a very generic:
> {{throw TProtocolException(TProtocolException::INVALID_DATA);}}
> (see - 
> https://git-wip-us.apache.org/repos/asf?p=thrift.git;a=blob;f=compiler/cpp/src/generate/t_cpp_generator.cc;h=298096d3265baa1f008501eb7c26bb4ae96ffa4b;hb=HEAD#l1372)
> It would be useful to indicate the invalid data field in this exception case.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (THRIFT-424) Steal ProtocolBuffers' VarInt implementation for C++

2015-09-30 Thread James E. King, III (JIRA)

[ 
https://issues.apache.org/jira/browse/THRIFT-424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14936841#comment-14936841
 ] 

James E. King, III commented on THRIFT-424:
---

[~jfarrell] did you mean to give this a Resolution of "Fixed"?

> Steal ProtocolBuffers' VarInt implementation for C++
> 
>
> Key: THRIFT-424
> URL: https://issues.apache.org/jira/browse/THRIFT-424
> Project: Thrift
>  Issue Type: Improvement
>  Components: C++ - Library
>Reporter: David Reiss
>Priority: Minor
> Fix For: 0.9.3
>
>
> Protocol Buffers use the same varint format as TCompactProtocol (not, as I 
> had previously believed, TDenseProtocol, which uses the MIDI VLQ format).  
> They have a much smarter C++ decoder than ours (and probably a better encoder 
> also).  Protocol Buffers is (are?) three-clause BSD licensed, which means 
> that we should be able to *cough* borrow *cough* their implementation and use 
> it for our C++ TCompactProtocol implementation.
> We might even be able to do the same for Java and Python.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[GitHub] thrift pull request: THRIFT-3361 Improve C# library

2015-09-30 Thread nsuke
Github user nsuke commented on the pull request:

https://github.com/apache/thrift/pull/630#issuecomment-144403888
  
Thank you for catching this !
I added a commit with this fix and releated test client setup, please have 
look at it too.


---
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] [Resolved] (THRIFT-2342) Add __FILE__ and __LINE__ to Thrift C++ excpetions

2015-09-30 Thread James E. King, III (JIRA)

 [ 
https://issues.apache.org/jira/browse/THRIFT-2342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James E. King, III resolved THRIFT-2342.

Resolution: Won't Fix
  Assignee: James E. King, III

Resolving as Won't Fix based on the title and description; will clone this into 
another issue tracking the usability of reporting INVALID_DATA at the protocol 
level.

> Add __FILE__ and __LINE__ to Thrift C++ excpetions
> --
>
> Key: THRIFT-2342
> URL: https://issues.apache.org/jira/browse/THRIFT-2342
> Project: Thrift
>  Issue Type: Improvement
>  Components: C++ - Compiler, C++ - Library
>Reporter: George Godik
>Assignee: James E. King, III
>Priority: Minor
>  Labels: newbie
>
> Thrift exceptions are somewhat difficult to trace from debug logs. I'd like 
> to add __FILE__AND__LINE__ as a second parameter to some exceptions to make 
> them easier to find.
> For example:
> Every time a required field is not set, the exception that gets generated is 
> a very generic
> throw TProtocolException(TProtocolException::INVALID_DATA)
> see - 
> https://git-wip-us.apache.org/repos/asf?p=thrift.git;a=blob;f=compiler/cpp/src/generate/t_cpp_generator.cc;h=298096d3265baa1f008501eb7c26bb4ae96ffa4b;hb=HEAD#l1372
> I think I'll start with patching up TProtocolExcpetion in the compiler and if 
> people like this I can make a separate issue and patch for other exceptions



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (THRIFT-3363) Reporting a missing required field to the client is not informative enough

2015-09-30 Thread James E. King, III (JIRA)
James E. King, III created THRIFT-3363:
--

 Summary: Reporting a missing required field to the client is not 
informative enough
 Key: THRIFT-3363
 URL: https://issues.apache.org/jira/browse/THRIFT-3363
 Project: Thrift
  Issue Type: Improvement
  Components: C++ - Compiler, C++ - Library
Reporter: James E. King, III
Assignee: James E. King, III
Priority: Minor


Thrift exceptions are somewhat difficult to trace from debug logs. I'd like to 
add __FILE__AND__LINE__ as a second parameter to some exceptions to make them 
easier to find.

For example:

Every time a required field is not set, the exception that gets generated is a 
very generic
throw TProtocolException(TProtocolException::INVALID_DATA)

see - 
https://git-wip-us.apache.org/repos/asf?p=thrift.git;a=blob;f=compiler/cpp/src/generate/t_cpp_generator.cc;h=298096d3265baa1f008501eb7c26bb4ae96ffa4b;hb=HEAD#l1372


I think I'll start with patching up TProtocolExcpetion in the compiler and if 
people like this I can make a separate issue and patch for other exceptions



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (THRIFT-3306) Java: TBinaryProtocol: Use 1 temp buffer instead of allocating 8

2015-09-30 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/THRIFT-3306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14936854#comment-14936854
 ] 

ASF GitHub Bot commented on THRIFT-3306:


Github user asfgit closed the pull request at:

https://github.com/apache/thrift/pull/596


> Java: TBinaryProtocol: Use 1 temp buffer instead of allocating 8
> 
>
> Key: THRIFT-3306
> URL: https://issues.apache.org/jira/browse/THRIFT-3306
> Project: Thrift
>  Issue Type: Improvement
>  Components: Java - Library
>Reporter: Evan Jones
>Priority: Minor
>
> TBinaryProtocol has a member buffer for reading and for serializing each of 
> the integer types. It can get by with only a single one: 8 bytes long for the 
> maximum length integer. This causes a significant reduction in allocations 
> and GC in cases that create the TBinaryProtocol to serialize a single 
> message, instead of reusing it.
> This passes "ant test". I ran the existing SerializationBenchmark and there 
> is no statistically significant difference (the average of 5 runs is smaller 
> on my machine, but I don't think we should read much into that).
> I have a JMH benchmark for this, and it shows that when the TBinaryProtocol 
> is allocated each time, this change is better, but is more or less the same 
> when you reuse the TBinaryProtocol in a loop.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (THRIFT-3363) Reporting a missing required field to the client is not informative enough

2015-09-30 Thread James E. King, III (JIRA)

 [ 
https://issues.apache.org/jira/browse/THRIFT-3363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James E. King, III updated THRIFT-3363:
---
Description: 
This may affect all languages, however it was initially reported against C++ by 
[~ggodik] in THRIFT-2342:

Every time a required field is not set, the exception that gets generated is a 
very generic:
{{throw TProtocolException(TProtocolException::INVALID_DATA);}}

(see - 
https://git-wip-us.apache.org/repos/asf?p=thrift.git;a=blob;f=compiler/cpp/src/generate/t_cpp_generator.cc;h=298096d3265baa1f008501eb7c26bb4ae96ffa4b;hb=HEAD#l1372)

It would be useful to indicate the invalid data field in this exception case.

  was:
This may affect all languages, however it was initially reported against C++.

Every time a required field is not set, the exception that gets generated is a 
very generic:
{{throw TProtocolException(TProtocolException::INVALID_DATA);}}

(see - 
https://git-wip-us.apache.org/repos/asf?p=thrift.git;a=blob;f=compiler/cpp/src/generate/t_cpp_generator.cc;h=298096d3265baa1f008501eb7c26bb4ae96ffa4b;hb=HEAD#l1372)

It would be useful to indicate the invalid data field in this exception case.


> Reporting a missing required field to the client is not informative enough
> --
>
> Key: THRIFT-3363
> URL: https://issues.apache.org/jira/browse/THRIFT-3363
> Project: Thrift
>  Issue Type: Improvement
>  Components: C++ - Compiler, C++ - Library
>Reporter: James E. King, III
>Assignee: James E. King, III
>Priority: Minor
>  Labels: newbie
>
> This may affect all languages, however it was initially reported against C++ 
> by [~ggodik] in THRIFT-2342:
> Every time a required field is not set, the exception that gets generated is 
> a very generic:
> {{throw TProtocolException(TProtocolException::INVALID_DATA);}}
> (see - 
> https://git-wip-us.apache.org/repos/asf?p=thrift.git;a=blob;f=compiler/cpp/src/generate/t_cpp_generator.cc;h=298096d3265baa1f008501eb7c26bb4ae96ffa4b;hb=HEAD#l1372)
> It would be useful to indicate the invalid data field in this exception case.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (THRIFT-3363) Reporting a missing required field to the client is not informative enough

2015-09-30 Thread James E. King, III (JIRA)

 [ 
https://issues.apache.org/jira/browse/THRIFT-3363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James E. King, III updated THRIFT-3363:
---
Description: 
This may affect all languages, however it was initially reported against C++.

Every time a required field is not set, the exception that gets generated is a 
very generic:
{{throw TProtocolException(TProtocolException::INVALID_DATA);}}

(see - 
https://git-wip-us.apache.org/repos/asf?p=thrift.git;a=blob;f=compiler/cpp/src/generate/t_cpp_generator.cc;h=298096d3265baa1f008501eb7c26bb4ae96ffa4b;hb=HEAD#l1372)

It would be useful to indicate the invalid data field in this exception case.

  was:
Thrift exceptions are somewhat difficult to trace from debug logs. I'd like to 
add __FILE__AND__LINE__ as a second parameter to some exceptions to make them 
easier to find.

For example:

Every time a required field is not set, the exception that gets generated is a 
very generic
throw TProtocolException(TProtocolException::INVALID_DATA)

see - 
https://git-wip-us.apache.org/repos/asf?p=thrift.git;a=blob;f=compiler/cpp/src/generate/t_cpp_generator.cc;h=298096d3265baa1f008501eb7c26bb4ae96ffa4b;hb=HEAD#l1372


I think I'll start with patching up TProtocolExcpetion in the compiler and if 
people like this I can make a separate issue and patch for other exceptions


> Reporting a missing required field to the client is not informative enough
> --
>
> Key: THRIFT-3363
> URL: https://issues.apache.org/jira/browse/THRIFT-3363
> Project: Thrift
>  Issue Type: Improvement
>  Components: C++ - Compiler, C++ - Library
>Reporter: James E. King, III
>Assignee: James E. King, III
>Priority: Minor
>  Labels: newbie
>
> This may affect all languages, however it was initially reported against C++.
> Every time a required field is not set, the exception that gets generated is 
> a very generic:
> {{throw TProtocolException(TProtocolException::INVALID_DATA);}}
> (see - 
> https://git-wip-us.apache.org/repos/asf?p=thrift.git;a=blob;f=compiler/cpp/src/generate/t_cpp_generator.cc;h=298096d3265baa1f008501eb7c26bb4ae96ffa4b;hb=HEAD#l1372)
> It would be useful to indicate the invalid data field in this exception case.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (THRIFT-3361) Improve C# library

2015-09-30 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/THRIFT-3361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14936846#comment-14936846
 ] 

ASF GitHub Bot commented on THRIFT-3361:


Github user nsuke commented on the pull request:

https://github.com/apache/thrift/pull/630#issuecomment-144403888
  
Thank you for catching this !
I added a commit with this fix and releated test client setup, please have 
look at it too.


> Improve C# library
> --
>
> Key: THRIFT-3361
> URL: https://issues.apache.org/jira/browse/THRIFT-3361
> Project: Thrift
>  Issue Type: Improvement
>  Components: C# - Compiler, C# - Library, Test Suite
>Reporter: Nobuaki Sukegawa
>Assignee: Jens Geyer
>
> h3. Server exception handling
> Servers didn't propagate exceptions in handler code to the client.
> Same as THRIFT-3349 (python) and THRIFT-3335 (ruby)
> h3. TBufferedTransport
> System.IO.BufferedStream inside this transport made it strongly tied to 
> underlying transport's stream state.
> More concretely, when used on top of TTLSSocket it crashed because underlying 
> SslStream is disposed by the socket while BufferedStream kept trying to touch 
> the disposed stream after that.
> So I removed BufferedStream and made it use System.IO.MemoryBuffer instead.
> * Can now work on top of TTLSSocket
> * Underlying transport no longer needs to be a TStreamTransport
> h3. TFramedTransport
> It was allocating new MemoryBuffer for nealy every write and read of frames.
> I made it allocate only once.
> h3. JSONProtocol
> * Can now handle Base64 with padding for binary fields (Fixes C# part of 
> THRIFT-3359)
> h3. TTLSSocket
> * Make client certificate optional
> h3. Test
> With this patch applied, all the cross test apps should be mostly valid.
> * Fix SSL setup
> * Semantic return code
> * Add testException and testMultiException
> * Add missing assertions



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[GitHub] thrift pull request: THRIFT-3306: Java: TBinaryProtocol: Use a sin...

2015-09-30 Thread asfgit
Github user asfgit closed the pull request at:

https://github.com/apache/thrift/pull/596


---
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-3361) Improve C# library

2015-09-30 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/THRIFT-3361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14939005#comment-14939005
 ] 

Hudson commented on THRIFT-3361:


SUCCESS: Integrated in Thrift #1673 (See 
[https://builds.apache.org/job/Thrift/1673/])
THRIFT-3361 Improve C# library Client: C# Patch: Nobuaki Sukegawa (jensg: rev 
178b813acd6dd3e334b88386be938415d9f3bf97)
* lib/csharp/test/ThriftTest/Makefile.am
* test/tests.json
* lib/csharp/Makefile.am
* lib/csharp/src/Transport/TTLSSocket.cs
* lib/csharp/src/Transport/TBufferedTransport.cs
* lib/csharp/test/ThriftTest/TestServer.cs
* compiler/cpp/src/generate/t_csharp_generator.cc
* lib/csharp/test/ThriftTest/Program.cs
* lib/csharp/test/ThriftTest/TestClient.cs
* lib/csharp/src/Transport/TTransport.cs
* test/known_failures_Linux.json
* lib/csharp/src/Transport/TFramedTransport.cs
THRIFT-3361 Improve C# library Client: C# Patch: Jens Geyer (jensg: rev 
96409d9dfecd8213726ee83ff1ac40695f8c)
* lib/csharp/src/Transport/TFramedTransport.cs
* lib/csharp/src/Transport/TBufferedTransport.cs


> Improve C# library
> --
>
> Key: THRIFT-3361
> URL: https://issues.apache.org/jira/browse/THRIFT-3361
> Project: Thrift
>  Issue Type: Improvement
>  Components: C# - Compiler, C# - Library, Test Suite
>Reporter: Nobuaki Sukegawa
>Assignee: Nobuaki Sukegawa
> Fix For: 0.9.4
>
> Attachments: 0001-THRIFT-3361-Improve-C-library.patch
>
>
> h3. Server exception handling
> Servers didn't propagate exceptions in handler code to the client.
> Same as THRIFT-3349 (python) and THRIFT-3335 (ruby)
> h3. TBufferedTransport
> System.IO.BufferedStream inside this transport made it strongly tied to 
> underlying transport's stream state.
> More concretely, when used on top of TTLSSocket it crashed because underlying 
> SslStream is disposed by the socket while BufferedStream kept trying to touch 
> the disposed stream after that.
> So I removed BufferedStream and made it use System.IO.MemoryBuffer instead.
> * Can now work on top of TTLSSocket
> * Underlying transport no longer needs to be a TStreamTransport
> h3. TFramedTransport
> It was allocating new MemoryBuffer for nealy every write and read of frames.
> I made it allocate only once.
> h3. JSONProtocol
> * Can now handle Base64 with padding for binary fields (Fixes C# part of 
> THRIFT-3359)
> h3. TTLSSocket
> * Make client certificate optional
> h3. Test
> With this patch applied, all the cross test apps should be mostly valid.
> * Fix SSL setup
> * Semantic return code
> * Add testException and testMultiException
> * Add missing assertions



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (THRIFT-3361) Improve C# library

2015-09-30 Thread Jens Geyer (JIRA)

 [ 
https://issues.apache.org/jira/browse/THRIFT-3361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jens Geyer updated THRIFT-3361:
---
Attachment: 0001-THRIFT-3361-Improve-C-library.patch

Additional [patch|^0001-THRIFT-3361-Improve-C-library.patch] to replace a bunch 
of C# exceptions with {{TTransportException}}, where appropriate.


> Improve C# library
> --
>
> Key: THRIFT-3361
> URL: https://issues.apache.org/jira/browse/THRIFT-3361
> Project: Thrift
>  Issue Type: Improvement
>  Components: C# - Compiler, C# - Library, Test Suite
>Reporter: Nobuaki Sukegawa
>Assignee: Jens Geyer
> Attachments: 0001-THRIFT-3361-Improve-C-library.patch
>
>
> h3. Server exception handling
> Servers didn't propagate exceptions in handler code to the client.
> Same as THRIFT-3349 (python) and THRIFT-3335 (ruby)
> h3. TBufferedTransport
> System.IO.BufferedStream inside this transport made it strongly tied to 
> underlying transport's stream state.
> More concretely, when used on top of TTLSSocket it crashed because underlying 
> SslStream is disposed by the socket while BufferedStream kept trying to touch 
> the disposed stream after that.
> So I removed BufferedStream and made it use System.IO.MemoryBuffer instead.
> * Can now work on top of TTLSSocket
> * Underlying transport no longer needs to be a TStreamTransport
> h3. TFramedTransport
> It was allocating new MemoryBuffer for nealy every write and read of frames.
> I made it allocate only once.
> h3. JSONProtocol
> * Can now handle Base64 with padding for binary fields (Fixes C# part of 
> THRIFT-3359)
> h3. TTLSSocket
> * Make client certificate optional
> h3. Test
> With this patch applied, all the cross test apps should be mostly valid.
> * Fix SSL setup
> * Semantic return code
> * Add testException and testMultiException
> * Add missing assertions



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (THRIFT-3361) Improve C# library

2015-09-30 Thread Jens Geyer (JIRA)

 [ 
https://issues.apache.org/jira/browse/THRIFT-3361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jens Geyer updated THRIFT-3361:
---
Assignee: Nobuaki Sukegawa  (was: Jens Geyer)

> Improve C# library
> --
>
> Key: THRIFT-3361
> URL: https://issues.apache.org/jira/browse/THRIFT-3361
> Project: Thrift
>  Issue Type: Improvement
>  Components: C# - Compiler, C# - Library, Test Suite
>Reporter: Nobuaki Sukegawa
>Assignee: Nobuaki Sukegawa
> Fix For: 0.9.4
>
> Attachments: 0001-THRIFT-3361-Improve-C-library.patch
>
>
> h3. Server exception handling
> Servers didn't propagate exceptions in handler code to the client.
> Same as THRIFT-3349 (python) and THRIFT-3335 (ruby)
> h3. TBufferedTransport
> System.IO.BufferedStream inside this transport made it strongly tied to 
> underlying transport's stream state.
> More concretely, when used on top of TTLSSocket it crashed because underlying 
> SslStream is disposed by the socket while BufferedStream kept trying to touch 
> the disposed stream after that.
> So I removed BufferedStream and made it use System.IO.MemoryBuffer instead.
> * Can now work on top of TTLSSocket
> * Underlying transport no longer needs to be a TStreamTransport
> h3. TFramedTransport
> It was allocating new MemoryBuffer for nealy every write and read of frames.
> I made it allocate only once.
> h3. JSONProtocol
> * Can now handle Base64 with padding for binary fields (Fixes C# part of 
> THRIFT-3359)
> h3. TTLSSocket
> * Make client certificate optional
> h3. Test
> With this patch applied, all the cross test apps should be mostly valid.
> * Fix SSL setup
> * Semantic return code
> * Add testException and testMultiException
> * Add missing assertions



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (THRIFT-3361) Improve C# library

2015-09-30 Thread Jens Geyer (JIRA)

 [ 
https://issues.apache.org/jira/browse/THRIFT-3361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jens Geyer resolved THRIFT-3361.

   Resolution: Fixed
Fix Version/s: 0.9.4

Committed including my patch to adjust exceptions thrown.
Thank you + keep up the good work!

> Improve C# library
> --
>
> Key: THRIFT-3361
> URL: https://issues.apache.org/jira/browse/THRIFT-3361
> Project: Thrift
>  Issue Type: Improvement
>  Components: C# - Compiler, C# - Library, Test Suite
>Reporter: Nobuaki Sukegawa
>Assignee: Jens Geyer
> Fix For: 0.9.4
>
> Attachments: 0001-THRIFT-3361-Improve-C-library.patch
>
>
> h3. Server exception handling
> Servers didn't propagate exceptions in handler code to the client.
> Same as THRIFT-3349 (python) and THRIFT-3335 (ruby)
> h3. TBufferedTransport
> System.IO.BufferedStream inside this transport made it strongly tied to 
> underlying transport's stream state.
> More concretely, when used on top of TTLSSocket it crashed because underlying 
> SslStream is disposed by the socket while BufferedStream kept trying to touch 
> the disposed stream after that.
> So I removed BufferedStream and made it use System.IO.MemoryBuffer instead.
> * Can now work on top of TTLSSocket
> * Underlying transport no longer needs to be a TStreamTransport
> h3. TFramedTransport
> It was allocating new MemoryBuffer for nealy every write and read of frames.
> I made it allocate only once.
> h3. JSONProtocol
> * Can now handle Base64 with padding for binary fields (Fixes C# part of 
> THRIFT-3359)
> h3. TTLSSocket
> * Make client certificate optional
> h3. Test
> With this patch applied, all the cross test apps should be mostly valid.
> * Fix SSL setup
> * Semantic return code
> * Add testException and testMultiException
> * Add missing assertions



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[GitHub] thrift pull request: THRIFT-3361 Improve C# library

2015-09-30 Thread asfgit
Github user asfgit closed the pull request at:

https://github.com/apache/thrift/pull/630


---
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-3361) Improve C# library

2015-09-30 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/THRIFT-3361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14938924#comment-14938924
 ] 

ASF GitHub Bot commented on THRIFT-3361:


Github user asfgit closed the pull request at:

https://github.com/apache/thrift/pull/630


> Improve C# library
> --
>
> Key: THRIFT-3361
> URL: https://issues.apache.org/jira/browse/THRIFT-3361
> Project: Thrift
>  Issue Type: Improvement
>  Components: C# - Compiler, C# - Library, Test Suite
>Reporter: Nobuaki Sukegawa
>Assignee: Jens Geyer
> Attachments: 0001-THRIFT-3361-Improve-C-library.patch
>
>
> h3. Server exception handling
> Servers didn't propagate exceptions in handler code to the client.
> Same as THRIFT-3349 (python) and THRIFT-3335 (ruby)
> h3. TBufferedTransport
> System.IO.BufferedStream inside this transport made it strongly tied to 
> underlying transport's stream state.
> More concretely, when used on top of TTLSSocket it crashed because underlying 
> SslStream is disposed by the socket while BufferedStream kept trying to touch 
> the disposed stream after that.
> So I removed BufferedStream and made it use System.IO.MemoryBuffer instead.
> * Can now work on top of TTLSSocket
> * Underlying transport no longer needs to be a TStreamTransport
> h3. TFramedTransport
> It was allocating new MemoryBuffer for nealy every write and read of frames.
> I made it allocate only once.
> h3. JSONProtocol
> * Can now handle Base64 with padding for binary fields (Fixes C# part of 
> THRIFT-3359)
> h3. TTLSSocket
> * Make client certificate optional
> h3. Test
> With this patch applied, all the cross test apps should be mostly valid.
> * Fix SSL setup
> * Semantic return code
> * Add testException and testMultiException
> * Add missing assertions



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (THRIFT-3306) Java: TBinaryProtocol: Use 1 temp buffer instead of allocating 8

2015-09-30 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/THRIFT-3306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14936890#comment-14936890
 ] 

Hudson commented on THRIFT-3306:


SUCCESS: Integrated in Thrift #1672 (See 
[https://builds.apache.org/job/Thrift/1672/])
THRIFT-3306: Java: TBinaryProtocol: Use a single temp byte[] buffer (roger: rev 
60aa640c3028a0c6314a2ae4e40d32e40f355464)
* lib/java/src/org/apache/thrift/protocol/TBinaryProtocol.java


> Java: TBinaryProtocol: Use 1 temp buffer instead of allocating 8
> 
>
> Key: THRIFT-3306
> URL: https://issues.apache.org/jira/browse/THRIFT-3306
> Project: Thrift
>  Issue Type: Improvement
>  Components: Java - Library
>Reporter: Evan Jones
>Assignee: Roger Meier
>Priority: Minor
>
> TBinaryProtocol has a member buffer for reading and for serializing each of 
> the integer types. It can get by with only a single one: 8 bytes long for the 
> maximum length integer. This causes a significant reduction in allocations 
> and GC in cases that create the TBinaryProtocol to serialize a single 
> message, instead of reusing it.
> This passes "ant test". I ran the existing SerializationBenchmark and there 
> is no statistically significant difference (the average of 5 runs is smaller 
> on my machine, but I don't think we should read much into that).
> I have a JMH benchmark for this, and it shows that when the TBinaryProtocol 
> is allocated each time, this change is better, but is more or less the same 
> when you reuse the TBinaryProtocol in a loop.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Resolved] (THRIFT-3306) Java: TBinaryProtocol: Use 1 temp buffer instead of allocating 8

2015-09-30 Thread Roger Meier (JIRA)

 [ 
https://issues.apache.org/jira/browse/THRIFT-3306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roger Meier resolved THRIFT-3306.
-
Resolution: Fixed
  Assignee: Roger Meier

efficiency matters, thanks!

> Java: TBinaryProtocol: Use 1 temp buffer instead of allocating 8
> 
>
> Key: THRIFT-3306
> URL: https://issues.apache.org/jira/browse/THRIFT-3306
> Project: Thrift
>  Issue Type: Improvement
>  Components: Java - Library
>Reporter: Evan Jones
>Assignee: Roger Meier
>Priority: Minor
>
> TBinaryProtocol has a member buffer for reading and for serializing each of 
> the integer types. It can get by with only a single one: 8 bytes long for the 
> maximum length integer. This causes a significant reduction in allocations 
> and GC in cases that create the TBinaryProtocol to serialize a single 
> message, instead of reusing it.
> This passes "ant test". I ran the existing SerializationBenchmark and there 
> is no statistically significant difference (the average of 5 runs is smaller 
> on my machine, but I don't think we should read much into that).
> I have a JMH benchmark for this, and it shows that when the TBinaryProtocol 
> is allocated each time, this change is better, but is more or less the same 
> when you reuse the TBinaryProtocol in a loop.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Reopened] (THRIFT-424) Steal ProtocolBuffers' VarInt implementation for C++

2015-09-30 Thread Jake Farrell (JIRA)

 [ 
https://issues.apache.org/jira/browse/THRIFT-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jake Farrell reopened THRIFT-424:
-

> Steal ProtocolBuffers' VarInt implementation for C++
> 
>
> Key: THRIFT-424
> URL: https://issues.apache.org/jira/browse/THRIFT-424
> Project: Thrift
>  Issue Type: Improvement
>  Components: C++ - Library
>Reporter: David Reiss
>Priority: Minor
> Fix For: 0.9.3
>
>
> Protocol Buffers use the same varint format as TCompactProtocol (not, as I 
> had previously believed, TDenseProtocol, which uses the MIDI VLQ format).  
> They have a much smarter C++ decoder than ours (and probably a better encoder 
> also).  Protocol Buffers is (are?) three-clause BSD licensed, which means 
> that we should be able to *cough* borrow *cough* their implementation and use 
> it for our C++ TCompactProtocol implementation.
> We might even be able to do the same for Java and Python.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (THRIFT-424) Steal ProtocolBuffers' VarInt implementation for C++

2015-09-30 Thread Jake Farrell (JIRA)

 [ 
https://issues.apache.org/jira/browse/THRIFT-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jake Farrell closed THRIFT-424.
---
Resolution: Won't Fix

thanks, thought i had set as wont fix

> Steal ProtocolBuffers' VarInt implementation for C++
> 
>
> Key: THRIFT-424
> URL: https://issues.apache.org/jira/browse/THRIFT-424
> Project: Thrift
>  Issue Type: Improvement
>  Components: C++ - Library
>Reporter: David Reiss
>Priority: Minor
> Fix For: 0.9.3
>
>
> Protocol Buffers use the same varint format as TCompactProtocol (not, as I 
> had previously believed, TDenseProtocol, which uses the MIDI VLQ format).  
> They have a much smarter C++ decoder than ours (and probably a better encoder 
> also).  Protocol Buffers is (are?) three-clause BSD licensed, which means 
> that we should be able to *cough* borrow *cough* their implementation and use 
> it for our C++ TCompactProtocol implementation.
> We might even be able to do the same for Java and Python.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (THRIFT-3237) Fix TNamedPipeServer::createNamedPipe memory leak

2015-09-30 Thread James E. King, III (JIRA)

 [ 
https://issues.apache.org/jira/browse/THRIFT-3237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James E. King, III updated THRIFT-3237:
---
Priority: Major  (was: Critical)

> Fix TNamedPipeServer::createNamedPipe memory leak
> -
>
> Key: THRIFT-3237
> URL: https://issues.apache.org/jira/browse/THRIFT-3237
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
>Affects Versions: 0.9.2
> Environment: Windows
>Reporter: Paweł Janicki
>Assignee: James E. King, III
> Attachments: 
> 0001-THRIFT-3237.-cpp-Fix-TNamedPipeServer-createNamedPip.patch
>
>
> Some resources are not released



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Assigned] (THRIFT-2630) windows7 64bit pc. ipv4 and ipv6 pc.can't use

2015-09-30 Thread James E. King, III (JIRA)

 [ 
https://issues.apache.org/jira/browse/THRIFT-2630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James E. King, III reassigned THRIFT-2630:
--

Assignee: James E. King, III

> windows7 64bit pc. ipv4 and ipv6 pc.can't use
> -
>
> Key: THRIFT-2630
> URL: https://issues.apache.org/jira/browse/THRIFT-2630
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
>Affects Versions: 0.9.1
> Environment: windows7 64bit pc. ipv4 and ipv6 pc.can't use
>Reporter: alan
>Assignee: James E. King, III
> Fix For: 1.0
>
> Attachments: TServerSocket.cpp
>
>
> net error no : 10093



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)