[jira] [Created] (THRIFT-1164) Segmentation fault on NULL pointer in t_js_generator::generate_const
Segmentation fault on NULL pointer in t_js_generator::generate_const
Key: THRIFT-1164
URL: https://issues.apache.org/jira/browse/THRIFT-1164
Project: Thrift
Issue Type: Bug
Components: JavaScript - Compiler
Affects Versions: 0.6.1
Reporter: Eric Rannaud
Attachments: js-compiler-generate_const-segfault-0.6.1.patch
--begin-- testcase.thrift
const i32 SHORT_STRING_LENGTH = 500;
--end--
(See traces below)
Explanation: For t_base_type, program_ is always NULL. (see main.cc and
t_base_type constructor)
But t_js_generator::generate_const() passes tconst->get_type() to
js_type_namespace(type). Then
std::string js_type_namespace(t_type* ttype) {
t_program* program = ttype->get_program();
// ...
return js_namespace(program);
}
std::string js_namespace(t_program* p) {
std::string ns = p->get_namespace("js"); // seg fault as p is NULL
This explains the NULL pointer but note that generate_const() is not doing the
right thing anyway. It shouldn't be printing the namespace of ttype, but it
should print the namespace where the const variable needs to be defined, i.e.
js_namespace(program_).
In the attached patch (against 0.6.1), generate_const() calls
js_namespace(program_) instead of js_type_namespace(ttype->get_type()).
The bug is gone in 0.7 but it was a silent fix consequence of
THRIFT-1045 Support "included"ed thrift files (r1071366)
This patch could be included in a 0.6.2 release if there is one.
$ valgrind thrift -strict --gen js testcase.thrift
==11242== Memcheck, a memory error detector
==11242== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==11242== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==11242== Command: thrift -strict --gen js testcase.thrift
==11242==
==11242== Invalid read of size 8
==11242==at 0x429781: std::_Rb_tree, std::_Select1st
>, std::less, std::allocator > >::find(std::string const&) const (stl_tree.h:488)
==11242==by 0x4AC112:
_ZN14t_js_generator12js_namespaceEP9t_program.clone.172 (stl_map.h:712)
==11242==by 0x4B0ADC: t_js_generator::generate_const(t_const*)
(t_js_generator.cc:203)
==11242==by 0x40CD68: t_generator::generate_consts(std::vector >) (t_generator.cc:91)
==11242==by 0x40DAAC: t_generator::generate_program() (t_generator.cc:50)
==11242==by 0x404B10: generate(t_program*, std::vector > const&) (main.cc:909)
==11242==by 0x408B11: main (main.cc:1217)
==11242== Address 0x110 is not stack'd, malloc'd or (recently) free'd
==11242==
==11242==
==11242== Process terminating with default action of signal 11 (SIGSEGV)
==11242== Access not within mapped region at address 0x110
==11242==at 0x429781: std::_Rb_tree, std::_Select1st
>, std::less, std::allocator > >::find(std::string const&) const (stl_tree.h:488)
==11242==by 0x4AC112:
_ZN14t_js_generator12js_namespaceEP9t_program.clone.172 (stl_map.h:712)
==11242==by 0x4B0ADC: t_js_generator::generate_const(t_const*)
(t_js_generator.cc:203)
==11242==by 0x40CD68: t_generator::generate_consts(std::vector >) (t_generator.cc:91)
==11242==by 0x40DAAC: t_generator::generate_program() (t_generator.cc:50)
==11242==by 0x404B10: generate(t_program*, std::vector > const&) (main.cc:909)
==11242==by 0x408B11: main (main.cc:1217)
==11242== If you believe this happened as a result of a stack
==11242== overflow in your program's main thread (unlikely but
==11242== possible), you can try to increase the size of the
==11242== main thread stack using the --main-stacksize= flag.
==11242== The main thread stack size used in this run was 8388608.
==11242==
==11242== HEAP SUMMARY:
==11242== in use at exit: 47,016 bytes in 410 blocks
==11242== total heap usage: 883 allocs, 473 frees, 88,445 bytes allocated
==11242==
==11242== LEAK SUMMARY:
==11242==definitely lost: 2,502 bytes in 98 blocks
==11242==indirectly lost: 4,404 bytes in 81 blocks
==11242== possibly lost: 3,818 bytes in 95 blocks
==11242==still reachable: 36,292 bytes in 136 blocks
==11242== suppressed: 0 bytes in 0 blocks
==11242== Rerun with --leak-check=full to see details of leaked memory
==11242==
==11242== For counts of detected and suppressed errors, rerun with: -v
==11242== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 6 from 6)
Segmentation fault (core dumped)
(gdb) r -strict --gen js testcase.thrift
Starting program: thrift -strict --gen js testcase.thrift
[Thread debugging using libthread_db enabled]
Program received signal SIGSEGV, Segmentation fault.
0x00429781 in std::_Rb_tree, std::allocator >,
std::pair, std::allocator
> const, std::basic_string, std::allocator >
>, std::_Select1st,
std::allocator > const, std::basic_string,
std::allocator > > >, std::less, std::allocator > >,
std::allocator,
std::allocator > const, std::basic_
[jira] [Updated] (THRIFT-1164) Segmentation fault on NULL pointer in t_js_generator::generate_const
[
https://issues.apache.org/jira/browse/THRIFT-1164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Rannaud updated THRIFT-1164:
-
Attachment: js-compiler-generate_const-segfault-0.6.1.patch
> Segmentation fault on NULL pointer in t_js_generator::generate_const
>
>
> Key: THRIFT-1164
> URL: https://issues.apache.org/jira/browse/THRIFT-1164
> Project: Thrift
> Issue Type: Bug
> Components: JavaScript - Compiler
>Affects Versions: 0.6.1
>Reporter: Eric Rannaud
> Attachments: js-compiler-generate_const-segfault-0.6.1.patch
>
>
> --begin-- testcase.thrift
> const i32 SHORT_STRING_LENGTH = 500;
> --end--
> (See traces below)
> Explanation: For t_base_type, program_ is always NULL. (see main.cc and
> t_base_type constructor)
> But t_js_generator::generate_const() passes tconst->get_type() to
> js_type_namespace(type). Then
> std::string js_type_namespace(t_type* ttype) {
> t_program* program = ttype->get_program();
> // ...
> return js_namespace(program);
> }
> std::string js_namespace(t_program* p) {
> std::string ns = p->get_namespace("js"); // seg fault as p is NULL
> This explains the NULL pointer but note that generate_const() is not doing
> the right thing anyway. It shouldn't be printing the namespace of ttype, but
> it should print the namespace where the const variable needs to be defined,
> i.e. js_namespace(program_).
> In the attached patch (against 0.6.1), generate_const() calls
> js_namespace(program_) instead of js_type_namespace(ttype->get_type()).
> The bug is gone in 0.7 but it was a silent fix consequence of
> THRIFT-1045 Support "included"ed thrift files (r1071366)
> This patch could be included in a 0.6.2 release if there is one.
> $ valgrind thrift -strict --gen js testcase.thrift
> ==11242== Memcheck, a memory error detector
> ==11242== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
> ==11242== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
> ==11242== Command: thrift -strict --gen js testcase.thrift
> ==11242==
> ==11242== Invalid read of size 8
> ==11242==at 0x429781: std::_Rb_tree const, std::string>, std::_Select1st std::string> >, std::less, std::allocator const, std::string> > >::find(std::string const&) const (stl_tree.h:488)
> ==11242==by 0x4AC112:
> _ZN14t_js_generator12js_namespaceEP9t_program.clone.172 (stl_map.h:712)
> ==11242==by 0x4B0ADC: t_js_generator::generate_const(t_const*)
> (t_js_generator.cc:203)
> ==11242==by 0x40CD68: t_generator::generate_consts(std::vector std::allocator >) (t_generator.cc:91)
> ==11242==by 0x40DAAC: t_generator::generate_program() (t_generator.cc:50)
> ==11242==by 0x404B10: generate(t_program*, std::vector std::allocator > const&) (main.cc:909)
> ==11242==by 0x408B11: main (main.cc:1217)
> ==11242== Address 0x110 is not stack'd, malloc'd or (recently) free'd
> ==11242==
> ==11242==
> ==11242== Process terminating with default action of signal 11 (SIGSEGV)
> ==11242== Access not within mapped region at address 0x110
> ==11242==at 0x429781: std::_Rb_tree const, std::string>, std::_Select1st std::string> >, std::less, std::allocator const, std::string> > >::find(std::string const&) const (stl_tree.h:488)
> ==11242==by 0x4AC112:
> _ZN14t_js_generator12js_namespaceEP9t_program.clone.172 (stl_map.h:712)
> ==11242==by 0x4B0ADC: t_js_generator::generate_const(t_const*)
> (t_js_generator.cc:203)
> ==11242==by 0x40CD68: t_generator::generate_consts(std::vector std::allocator >) (t_generator.cc:91)
> ==11242==by 0x40DAAC: t_generator::generate_program() (t_generator.cc:50)
> ==11242==by 0x404B10: generate(t_program*, std::vector std::allocator > const&) (main.cc:909)
> ==11242==by 0x408B11: main (main.cc:1217)
> ==11242== If you believe this happened as a result of a stack
> ==11242== overflow in your program's main thread (unlikely but
> ==11242== possible), you can try to increase the size of the
> ==11242== main thread stack using the --main-stacksize= flag.
> ==11242== The main thread stack size used in this run was 8388608.
> ==11242==
> ==11242== HEAP SUMMARY:
> ==11242== in use at exit: 47,016 bytes in 410 blocks
> ==11242== total heap usage: 883 allocs, 473 frees, 88,445 bytes allocated
> ==11242==
> ==11242== LEAK SUMMARY:
> ==11242==definitely lost: 2,502 bytes in 98 blocks
> ==11242==indirectly lost: 4,404 bytes in 81 blocks
> ==11242== possibly lost: 3,818 bytes in 95 blocks
> ==11242==still reachable: 36,292 bytes in 136 blocks
> ==11242== suppressed: 0 bytes in 0 blocks
> ==11242== Rerun with --leak-check=full to see details of leaked memory
> ==11242==
> ==11242== For counts of detected and suppressed errors, rerun with: -v
> ==11242== ERROR SUMMARY: 1 er
[jira] [Issue Comment Edited] (THRIFT-1115) python TBase class for dynamic (de)serialization, and __slots__ option for memory savings
[
https://issues.apache.org/jira/browse/THRIFT-1115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13027455#comment-13027455
]
Will Pierce edited comment on THRIFT-1115 at 5/7/11 1:20 AM:
-
Does the updated patch address all your concerns/suggestions? (I think it's a
lot better than the first version, especially the exception class generation.)
I'm interested in knowing if this is likely to be committed or not. I don't
mind going through more revisions, if there's more improvements you'd like to
see.
Thanks!
was (Author: willp):
Does the updated patch address all your concerns/suggestions? (I think
it's a lot better than the first version, especially the exception class
generation.)
> python TBase class for dynamic (de)serialization, and __slots__ option for
> memory savings
> -
>
> Key: THRIFT-1115
> URL: https://issues.apache.org/jira/browse/THRIFT-1115
> Project: Thrift
> Issue Type: New Feature
> Components: Python - Compiler, Python - Library
>Reporter: Will Pierce
>Assignee: Will Pierce
> Attachments: THRIFT-1115.python_dynamic_code_and_slots_v1.patch,
> THRIFT-1115.python_dynamic_code_and_slots_v2.patch,
> THRIFT-1115.python_dynamic_code_and_slots_v3.patch, test_dynser.py,
> test_size.py
>
>
> This patch adds several new features to the compiler for python and the
> python libraries, and exercises the new features with expanded unit testing.
> This adds support for generating python classes that have no {{read()}} or
> {{write()}} methods. Instead, the generated classes inherit from a new base
> class, {{TProtocolDynamic}}. This new class implements the de/serialization
> with {{read()}} and {{write()}} methods that iterate over the derived class's
> "{{thrift_spec}}" class member that describes the structure and types of the
> thrift. This dynamic evaluation works with both binary and compact
> protocols, and has the same hook as before for delegating de/serialization to
> fastbinary.so for the "accelerated binary" protocol. This new baseclass
> {{read()}} method may even be more efficient than the generated explicit
> {{read()}} code for objects with lots of attributes because it doesn't have a
> case/switch style series of "{{if field_id == X...}}" nested inside a loop.
> Instead, it indexes the decoded field ID into the {{thrift_spec}} tuple
> directly. That efficiency gain is probably just noise though, since the
> dynamic process probably uses more CPU later on, though I haven't benchmarked
> it. (Up[date: see the benchmarking results posted below for
> construction/serialization/deserialization comparisons.)
> If the 'dynamic' flag is given as a -gen py: flag to the compiler, then the
> generated classes no longer get individual {{\_\_repr\_\_}} and
> {{\_\_eq\_\_}} and {{\_\_ne\_\_}} methods, instead they inherit from the
> TProtocolDynamic base class implementation, which uses {{\_\_slots\_\_}}
> instead of {{\_\_dict\_\_}} for repr and equality testing.
> When "dynamic" python classes are generated, they have very little code, just
> a constructor and class data. All the work of serialization and
> deserialization is done by the base class. This produces about 980 lines for
> DebugProtoTest vs. 3540 lines in default "\-gen py" mode, or about 1/3 the
> original code size.
> The {{\_\_slots\_\_}} support is available without requiring the dynamic base
> class, so users can save memory using the slots flag to generate non-dict
> based instances. The memory difference between dict and slots based objects
> is hard to measure, but seems to be around 10x smaller using slots, as long
> as the base class also uses {{\_\_slots\_\_}}. If the generated classes are
> old-style, and use slots, there's no memory savings at all, because the base
> class still creates a {{\_\_dict\_\_}} object for every instance. Python is
> just tricky when it comes to using {{\_\_slots\_\_}} best.
> The memory savings is pretty astounding using new-style classes and
> {{\_\_slots\_\_}}. Building DebugProtoTest.thrift with: -gen
> py:dynamic,slots versus \-gen py results in some pretty amazing memory
> savings. I tested by instantiating 1 million of the heavy
> DebugProtoTest.thrift's {{CompactProtoTestStruct()}}, which has 49 attributes
> in it, using regular "\-gen py" code versus "{{\-gen py:dynamic,slots}}" and
> compared the VmRSS resident memory usage of both processes. I didn't set any
> values to any attributes, so every attribute was left with the null value,
> None. The slots technique used 441 MB with slots vs. 3485 MB using
> non-slots, non-dynamic generated code. That's about 13% of the original
> size, or 87% memory savings.
> I tried the
[jira] [Issue Comment Edited] (THRIFT-1163) How can i use multi service in one program?
[
https://issues.apache.org/jira/browse/THRIFT-1163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13030071#comment-13030071
]
Dragan Okiljevic edited comment on THRIFT-1163 at 5/6/11 6:25 PM:
--
You would need to launch two instances of thrift server from your program, each
instance for one service and these two servers would need to listen to
different ports. (Use fork(), thrift thread implementation or something else to
launch servers at a same time).
There is also another solution available as a patch: a single server that
multiplexes services. Take a look at THRIFT-66 and THRIFT-563 for multiplexing
services.
was (Author: dragan.okiljevic):
You would need to launh two instances of thrift server from your program,
each instance for one service and these two servers would need to listen to
different ports. (Use fork(), thrift thread implementation or something else to
launch servers at a same time).
There is also another solution available as a patch: a single server that
multiplexes services. Take a look at THRIFT-66 and THRIFT-563 for multiplexing
services.
> How can i use multi service in one program?
> ---
>
> Key: THRIFT-1163
> URL: https://issues.apache.org/jira/browse/THRIFT-1163
> Project: Thrift
> Issue Type: Question
> Components: C++ - Library
>Affects Versions: 0.6.1
>Reporter: qiutao
>Assignee: Jake Farrell
> Labels: features
> Fix For: 0.6.1
>
>
> For example,i have two service like this:
> service FirstService
> {
> string hello()
> }
> service SecondService
> {
> string hello()
> }
> the generated code have two skeleton server file,how can i use them in one
> program?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (THRIFT-1163) How can i use multi service in one program?
[
https://issues.apache.org/jira/browse/THRIFT-1163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13030071#comment-13030071
]
Dragan Okiljevic commented on THRIFT-1163:
--
You would need to launh two instances of thrift server from your program, each
instance for one service and these two servers would need to listen to
different ports. (Use fork(), thrift thread implementation or something else to
launch servers at a same time).
There is also another solution available as a patch: a single server that
multiplexes services. Take a look at THRIFT-66 and THRIFT-563 for multiplexing
services.
> How can i use multi service in one program?
> ---
>
> Key: THRIFT-1163
> URL: https://issues.apache.org/jira/browse/THRIFT-1163
> Project: Thrift
> Issue Type: Question
> Components: C++ - Library
>Affects Versions: 0.6.1
>Reporter: qiutao
>Assignee: Jake Farrell
> Labels: features
> Fix For: 0.6.1
>
>
> For example,i have two service like this:
> service FirstService
> {
> string hello()
> }
> service SecondService
> {
> string hello()
> }
> the generated code have two skeleton server file,how can i use them in one
> program?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (THRIFT-1163) How can i use multi service in one program?
[
https://issues.apache.org/jira/browse/THRIFT-1163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jake Farrell resolved THRIFT-1163.
--
Resolution: Not A Problem
Assignee: Jake Farrell
Please ask questions like this to the user or dev mailing list. You are able to
have multiple service blocks within one definition file. The compiler will
generate separate files for each service as shown below.
gen-cpp/
|-- FirstService.cpp
|-- FirstService.h
|-- FirstService_server.skeleton.cpp
|-- SecondService.cpp
|-- SecondService.h
|-- SecondService_server.skeleton.cpp
|-- test_constants.cpp
|-- test_constants.h
|-- test_types.cpp
`-- test_types.h
gen-java/
|-- FirstService.java
`-- SecondService.java
> How can i use multi service in one program?
> ---
>
> Key: THRIFT-1163
> URL: https://issues.apache.org/jira/browse/THRIFT-1163
> Project: Thrift
> Issue Type: Question
> Components: C++ - Library
>Affects Versions: 0.6.1
>Reporter: qiutao
>Assignee: Jake Farrell
> Labels: features
> Fix For: 0.6.1
>
>
> For example,i have two service like this:
> service FirstService
> {
> string hello()
> }
> service SecondService
> {
> string hello()
> }
> the generated code have two skeleton server file,how can i use them in one
> program?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (THRIFT-1163) How can i use multi service in one program?
How can i use multi service in one program?
---
Key: THRIFT-1163
URL: https://issues.apache.org/jira/browse/THRIFT-1163
Project: Thrift
Issue Type: Question
Components: C++ - Library
Affects Versions: 0.6.1
Reporter: qiutao
Fix For: 0.6.1
For example,i have two service like this:
service FirstService
{
string hello()
}
service SecondService
{
string hello()
}
the generated code have two skeleton server file,how can i use them in one
program?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (THRIFT-1162) THttpClient - provide ReadByte() method for server response
[
https://issues.apache.org/jira/browse/THRIFT-1162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ag9 updated THRIFT-1162:
Patch Info: [Patch Available]
> THttpClient - provide ReadByte() method for server response
> ---
>
> Key: THRIFT-1162
> URL: https://issues.apache.org/jira/browse/THRIFT-1162
> Project: Thrift
> Issue Type: New Feature
> Components: C# - Library
> Environment: win2k, .net2
>Reporter: ag9
>Priority: Trivial
> Labels: thrift
> Attachments: THttpClient.cs
>
> Original Estimate: 4m
> Remaining Estimate: 4m
>
> For now THttpClient supports just one way to read data from server response -
> the method Read(byte[] buf, int off, int len). But at the moment of getting
> data user don't know size of getting data so can't determine size of array
> instance exactly (see sample below).
> By example,
> server code (simple asp.net app):
> {code:java}
> public class post : IHttpHandler {
>
> public void ProcessRequest (HttpContext context) {
> if (context.Request.UserAgent=="C#/THttpClient") {
> context.Response.ContentType = "application/text";
> context.Response.ContentEncoding =
> System.Text.Encoding.Default;
> context.Response.Write("thrift server response");
> }
> }
> ...
> {code}
> client code (console app):
> {code:java}
> Uri uri = new Uri("http://localhost:3968/TimeServerSample/post.ashx";);
> THttpClient transport = new THttpClient(uri);
> transport.Proxy = WebRequest.DefaultWebProxy;
> string postData = "test";
> transport.Write(UTF8Encoding.UTF8.GetBytes(postData));
> transport.Flush();
> byte[] arr = new byte[1024];
> transport.Read(arr, 0, 1024);
> Console.WriteLine(System.Text.UTF8Encoding.UTF8.GetString(arr));
> {code}
> Would be better to define (in addition to Read) method *ReadByte* (like
> public method in Stream class) for getting byte array byte for a byte.
> Something like that:
> {code:java}
> System.Collections.ArrayList al = new System.Collections.ArrayList();
> int res = 0;
> while ( res != -1) {
> res = transport.ReadByte();
> if (res > -1) al.Add((byte)res);
> }
> byte[] bytes = (byte[])al.ToArray(typeof(byte));
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (THRIFT-1162) THttpClient - provide ReadByte() method for server response
[
https://issues.apache.org/jira/browse/THRIFT-1162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ag9 updated THRIFT-1162:
Attachment: THttpClient.cs
The attached file THttpClient.cs contains method *ReadByte()*. For getting data
it method uses similar native method of *Stream* object *ReadByte()*.
Original copy of THttpClient.cs was take from
[THRIFT-1159|https://issues.apache.org/jira/browse/THRIFT-1159]
(it's not clear copy from svn) and has been changed according to issue cases
(added method).
> THttpClient - provide ReadByte() method for server response
> ---
>
> Key: THRIFT-1162
> URL: https://issues.apache.org/jira/browse/THRIFT-1162
> Project: Thrift
> Issue Type: New Feature
> Components: C# - Library
> Environment: win2k, .net2
>Reporter: ag9
>Priority: Trivial
> Labels: thrift
> Attachments: THttpClient.cs
>
> Original Estimate: 4m
> Remaining Estimate: 4m
>
> For now THttpClient supports just one way to read data from server response -
> the method Read(byte[] buf, int off, int len). But at the moment of getting
> data user don't know size of getting data so can't determine size of array
> instance exactly (see sample below).
> By example,
> server code (simple asp.net app):
> {code:java}
> public class post : IHttpHandler {
>
> public void ProcessRequest (HttpContext context) {
> if (context.Request.UserAgent=="C#/THttpClient") {
> context.Response.ContentType = "application/text";
> context.Response.ContentEncoding =
> System.Text.Encoding.Default;
> context.Response.Write("thrift server response");
> }
> }
> ...
> {code}
> client code (console app):
> {code:java}
> Uri uri = new Uri("http://localhost:3968/TimeServerSample/post.ashx";);
> THttpClient transport = new THttpClient(uri);
> transport.Proxy = WebRequest.DefaultWebProxy;
> string postData = "test";
> transport.Write(UTF8Encoding.UTF8.GetBytes(postData));
> transport.Flush();
> byte[] arr = new byte[1024];
> transport.Read(arr, 0, 1024);
> Console.WriteLine(System.Text.UTF8Encoding.UTF8.GetString(arr));
> {code}
> Would be better to define (in addition to Read) method *ReadByte* (like
> public method in Stream class) for getting byte array byte for a byte.
> Something like that:
> {code:java}
> System.Collections.ArrayList al = new System.Collections.ArrayList();
> int res = 0;
> while ( res != -1) {
> res = transport.ReadByte();
> if (res > -1) al.Add((byte)res);
> }
> byte[] bytes = (byte[])al.ToArray(typeof(byte));
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (THRIFT-1162) THttpClient - provide ReadByte() method for server response
THttpClient - provide ReadByte() method for server response
---
Key: THRIFT-1162
URL: https://issues.apache.org/jira/browse/THRIFT-1162
Project: Thrift
Issue Type: New Feature
Components: C# - Library
Environment: win2k, .net2
Reporter: ag9
Priority: Trivial
For now THttpClient supports just one way to read data from server response -
the method Read(byte[] buf, int off, int len). But at the moment of getting
data user don't know size of getting data so can't determine size of array
instance exactly (see sample below).
By example,
server code (simple asp.net app):
{code:java}
public class post : IHttpHandler {
public void ProcessRequest (HttpContext context) {
if (context.Request.UserAgent=="C#/THttpClient") {
context.Response.ContentType = "application/text";
context.Response.ContentEncoding =
System.Text.Encoding.Default;
context.Response.Write("thrift server response");
}
}
...
{code}
client code (console app):
{code:java}
Uri uri = new Uri("http://localhost:3968/TimeServerSample/post.ashx";);
THttpClient transport = new THttpClient(uri);
transport.Proxy = WebRequest.DefaultWebProxy;
string postData = "test";
transport.Write(UTF8Encoding.UTF8.GetBytes(postData));
transport.Flush();
byte[] arr = new byte[1024];
transport.Read(arr, 0, 1024);
Console.WriteLine(System.Text.UTF8Encoding.UTF8.GetString(arr));
{code}
Would be better to define (in addition to Read) method *ReadByte* (like public
method in Stream class) for getting byte array byte for a byte. Something like
that:
{code:java}
System.Collections.ArrayList al = new System.Collections.ArrayList();
int res = 0;
while ( res != -1) {
res = transport.ReadByte();
if (res > -1) al.Add((byte)res);
}
byte[] bytes = (byte[])al.ToArray(typeof(byte));
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
