Re: HttpClient Connection close bugs

[Usman Ismail]

Observed in the c++ code but I also saw that objective c does not have the 
header

Sent from my iPhone

On 2011-04-26, at 8:09 PM, Seth Hitchings  wrote:

> What language was that? We use the Objective-C client in our Mac app and
> don't have any issues.
> 
> Seth
> 
> On Tue, Apr 26, 2011 at 6:56 PM, Kerr, Rowan  wrote:
> 
>> Observed behavior was that reading an object from response would not
>> return the object until connection closed.
>> 
>> 
>> On 11-04-26 2:32 PM, "Mark Slee"  wrote:
>> 
>>> This should definitely be a configurable option, but I think the default
>>> should definitely be *not* to send the close header. As far as I
>>> remember, the Thrift HTTP clients were intentionally written to support
>>> keep-alive, which is definitely the best way to use them if making
>>> repeated requests.
>>> 
>>> Philosophically, I think we should err on making it easier to get things
>>> right in the high-volume, high-performance case. IMO, keep-alive should
>>> be something that "just works" if you do the naïve thing (construct a
>>> THttpClient and issue multiple subsequent RPC calls on it with no extra
>>> lines of code in between).
>>> 
>>> If you're closing your connections after every unique request, your perf
>>> requirements are probably less stringent than someone who's pushing many
>>> requests over shared connections.
>>> 
>>> Cheers,
>>> mcslee
>>> 
>>> 
>>> -Original Message-
>>> From: Usman Ismail [mailto:0x...@gmail.com]
>>> Sent: Tuesday, April 26, 2011 11:22 AM
>>> To: dev@thrift.apache.org
>>> Subject: Re: HttpClient Connection close bugs
>>> 
>>> As far as I can tell for c++ and objective c we are not actually using
>>> persistent http, i.e. we do not reuse open connections. Hence not
>>> setting the close header just means it takes longer to close the
>>> connection. In the long run I agree  we should explore use of
>>> persistent http connections as well as user specified headers.
>>> 
>>> --usman
>>> 
>>> On Tue, Apr 26, 2011 at 2:12 PM, Seth Hitchings 
>> wrote:
 Using keep-alive should improve performance, not degrade it. Adding
 Connection: close would significantly degrade performance, especially
 for
 HTTPS connections.
 
 In general, it would be great if all of the HTTP client transports
 exposed
 the ability to customize headers, so that an app could override
 defaults or
 add custom headers without modifying the client itself.
 
 Seth
 
 On Tue, Apr 26, 2011 at 10:43 AM, Usman Ismail <0x...@gmail.com>
 wrote:
 
> Hi,
> 
> I had a look at the Objective C and C++ http client code and noticed
> that it does not supply the Connection: close header. This means that
> webservers keep the connection alive assuming its a persistent
> connection. This slows down client side request processing
> significantly and also wastes server resources. I created issues 1153
> and 1154 for c++ and objective c respectively it would be great to
> have then in the next release.
> 
> I also noticed a similar issue in java although I am not sure whether
> the the change is needed in java or whether underlying layers take
> care of it.
> 
> --regards
> Usman Ismail
> 
 
>>> 
>> 
>> 

Re: HttpClient Connection close bugs

[Seth Hitchings]

What language was that? We use the Objective-C client in our Mac app and
don't have any issues.

Seth

On Tue, Apr 26, 2011 at 6:56 PM, Kerr, Rowan  wrote:

> Observed behavior was that reading an object from response would not
> return the object until connection closed.
>
>
> On 11-04-26 2:32 PM, "Mark Slee"  wrote:
>
> >This should definitely be a configurable option, but I think the default
> >should definitely be *not* to send the close header. As far as I
> >remember, the Thrift HTTP clients were intentionally written to support
> >keep-alive, which is definitely the best way to use them if making
> >repeated requests.
> >
> >Philosophically, I think we should err on making it easier to get things
> >right in the high-volume, high-performance case. IMO, keep-alive should
> >be something that "just works" if you do the naïve thing (construct a
> >THttpClient and issue multiple subsequent RPC calls on it with no extra
> >lines of code in between).
> >
> >If you're closing your connections after every unique request, your perf
> >requirements are probably less stringent than someone who's pushing many
> >requests over shared connections.
> >
> >Cheers,
> >mcslee
> >
> >
> >-Original Message-
> >From: Usman Ismail [mailto:0x...@gmail.com]
> >Sent: Tuesday, April 26, 2011 11:22 AM
> >To: dev@thrift.apache.org
> >Subject: Re: HttpClient Connection close bugs
> >
> >As far as I can tell for c++ and objective c we are not actually using
> >persistent http, i.e. we do not reuse open connections. Hence not
> >setting the close header just means it takes longer to close the
> >connection. In the long run I agree  we should explore use of
> >persistent http connections as well as user specified headers.
> >
> >--usman
> >
> >On Tue, Apr 26, 2011 at 2:12 PM, Seth Hitchings 
> wrote:
> >> Using keep-alive should improve performance, not degrade it. Adding
> >> Connection: close would significantly degrade performance, especially
> >>for
> >> HTTPS connections.
> >>
> >> In general, it would be great if all of the HTTP client transports
> >>exposed
> >> the ability to customize headers, so that an app could override
> >>defaults or
> >> add custom headers without modifying the client itself.
> >>
> >> Seth
> >>
> >> On Tue, Apr 26, 2011 at 10:43 AM, Usman Ismail <0x...@gmail.com>
> >>wrote:
> >>
> >>> Hi,
> >>>
> >>> I had a look at the Objective C and C++ http client code and noticed
> >>> that it does not supply the Connection: close header. This means that
> >>> webservers keep the connection alive assuming its a persistent
> >>> connection. This slows down client side request processing
> >>> significantly and also wastes server resources. I created issues 1153
> >>> and 1154 for c++ and objective c respectively it would be great to
> >>> have then in the next release.
> >>>
> >>> I also noticed a similar issue in java although I am not sure whether
> >>> the the change is needed in java or whether underlying layers take
> >>> care of it.
> >>>
> >>> --regards
> >>> Usman Ismail
> >>>
> >>
> >
>
>

RE: HttpClient Connection close bugs

[Mark Slee]

Hmm, that sounds like a bug to me then. Not familiar with the specifics, but a 
"correct" HTTP client implementation should definitely not block on the 
connection closing to complete a read. Maybe it is being too greedy about 
filling up a buffer or something?

I haven't been in this code for quite some time, so hard to comment 
definitively. Just my philosophical opinion on this one -- moving to always 
close the connection seems like a workable but suboptimal fix.

 
-Original Message-
From: Kerr, Rowan [mailto:rk...@ea.com] 
Sent: Tuesday, April 26, 2011 3:56 PM
To: dev@thrift.apache.org
Subject: Re: HttpClient Connection close bugs

Observed behavior was that reading an object from response would not
return the object until connection closed.


On 11-04-26 2:32 PM, "Mark Slee"  wrote:

>This should definitely be a configurable option, but I think the default
>should definitely be *not* to send the close header. As far as I
>remember, the Thrift HTTP clients were intentionally written to support
>keep-alive, which is definitely the best way to use them if making
>repeated requests.
>
>Philosophically, I think we should err on making it easier to get things
>right in the high-volume, high-performance case. IMO, keep-alive should
>be something that "just works" if you do the naïve thing (construct a
>THttpClient and issue multiple subsequent RPC calls on it with no extra
>lines of code in between).
>
>If you're closing your connections after every unique request, your perf
>requirements are probably less stringent than someone who's pushing many
>requests over shared connections.
>
>Cheers,
>mcslee
>
>
>-Original Message-
>From: Usman Ismail [mailto:0x...@gmail.com]
>Sent: Tuesday, April 26, 2011 11:22 AM
>To: dev@thrift.apache.org
>Subject: Re: HttpClient Connection close bugs
>
>As far as I can tell for c++ and objective c we are not actually using
>persistent http, i.e. we do not reuse open connections. Hence not
>setting the close header just means it takes longer to close the
>connection. In the long run I agree  we should explore use of
>persistent http connections as well as user specified headers.
>
>--usman
>
>On Tue, Apr 26, 2011 at 2:12 PM, Seth Hitchings  wrote:
>> Using keep-alive should improve performance, not degrade it. Adding
>> Connection: close would significantly degrade performance, especially
>>for
>> HTTPS connections.
>>
>> In general, it would be great if all of the HTTP client transports
>>exposed
>> the ability to customize headers, so that an app could override
>>defaults or
>> add custom headers without modifying the client itself.
>>
>> Seth
>>
>> On Tue, Apr 26, 2011 at 10:43 AM, Usman Ismail <0x...@gmail.com>
>>wrote:
>>
>>> Hi,
>>>
>>> I had a look at the Objective C and C++ http client code and noticed
>>> that it does not supply the Connection: close header. This means that
>>> webservers keep the connection alive assuming its a persistent
>>> connection. This slows down client side request processing
>>> significantly and also wastes server resources. I created issues 1153
>>> and 1154 for c++ and objective c respectively it would be great to
>>> have then in the next release.
>>>
>>> I also noticed a similar issue in java although I am not sure whether
>>> the the change is needed in java or whether underlying layers take
>>> care of it.
>>>
>>> --regards
>>> Usman Ismail
>>>
>>
>

Re: HttpClient Connection close bugs

[Kerr, Rowan]

Observed behavior was that reading an object from response would not
return the object until connection closed.


On 11-04-26 2:32 PM, "Mark Slee"  wrote:

>This should definitely be a configurable option, but I think the default
>should definitely be *not* to send the close header. As far as I
>remember, the Thrift HTTP clients were intentionally written to support
>keep-alive, which is definitely the best way to use them if making
>repeated requests.
>
>Philosophically, I think we should err on making it easier to get things
>right in the high-volume, high-performance case. IMO, keep-alive should
>be something that "just works" if you do the naïve thing (construct a
>THttpClient and issue multiple subsequent RPC calls on it with no extra
>lines of code in between).
>
>If you're closing your connections after every unique request, your perf
>requirements are probably less stringent than someone who's pushing many
>requests over shared connections.
>
>Cheers,
>mcslee
>
>
>-Original Message-
>From: Usman Ismail [mailto:0x...@gmail.com]
>Sent: Tuesday, April 26, 2011 11:22 AM
>To: dev@thrift.apache.org
>Subject: Re: HttpClient Connection close bugs
>
>As far as I can tell for c++ and objective c we are not actually using
>persistent http, i.e. we do not reuse open connections. Hence not
>setting the close header just means it takes longer to close the
>connection. In the long run I agree  we should explore use of
>persistent http connections as well as user specified headers.
>
>--usman
>
>On Tue, Apr 26, 2011 at 2:12 PM, Seth Hitchings  wrote:
>> Using keep-alive should improve performance, not degrade it. Adding
>> Connection: close would significantly degrade performance, especially
>>for
>> HTTPS connections.
>>
>> In general, it would be great if all of the HTTP client transports
>>exposed
>> the ability to customize headers, so that an app could override
>>defaults or
>> add custom headers without modifying the client itself.
>>
>> Seth
>>
>> On Tue, Apr 26, 2011 at 10:43 AM, Usman Ismail <0x...@gmail.com>
>>wrote:
>>
>>> Hi,
>>>
>>> I had a look at the Objective C and C++ http client code and noticed
>>> that it does not supply the Connection: close header. This means that
>>> webservers keep the connection alive assuming its a persistent
>>> connection. This slows down client side request processing
>>> significantly and also wastes server resources. I created issues 1153
>>> and 1154 for c++ and objective c respectively it would be great to
>>> have then in the next release.
>>>
>>> I also noticed a similar issue in java although I am not sure whether
>>> the the change is needed in java or whether underlying layers take
>>> care of it.
>>>
>>> --regards
>>> Usman Ismail
>>>
>>
>

RE: HttpClient Connection close bugs

[Mark Slee]

This should definitely be a configurable option, but I think the default should 
definitely be *not* to send the close header. As far as I remember, the Thrift 
HTTP clients were intentionally written to support keep-alive, which is 
definitely the best way to use them if making repeated requests.

Philosophically, I think we should err on making it easier to get things right 
in the high-volume, high-performance case. IMO, keep-alive should be something 
that "just works" if you do the naïve thing (construct a THttpClient and issue 
multiple subsequent RPC calls on it with no extra lines of code in between).

If you're closing your connections after every unique request, your perf 
requirements are probably less stringent than someone who's pushing many 
requests over shared connections.

Cheers,
mcslee


-Original Message-
From: Usman Ismail [mailto:0x...@gmail.com] 
Sent: Tuesday, April 26, 2011 11:22 AM
To: dev@thrift.apache.org
Subject: Re: HttpClient Connection close bugs

As far as I can tell for c++ and objective c we are not actually using
persistent http, i.e. we do not reuse open connections. Hence not
setting the close header just means it takes longer to close the
connection. In the long run I agree  we should explore use of
persistent http connections as well as user specified headers.

--usman

On Tue, Apr 26, 2011 at 2:12 PM, Seth Hitchings  wrote:
> Using keep-alive should improve performance, not degrade it. Adding
> Connection: close would significantly degrade performance, especially for
> HTTPS connections.
>
> In general, it would be great if all of the HTTP client transports exposed
> the ability to customize headers, so that an app could override defaults or
> add custom headers without modifying the client itself.
>
> Seth
>
> On Tue, Apr 26, 2011 at 10:43 AM, Usman Ismail <0x...@gmail.com> wrote:
>
>> Hi,
>>
>> I had a look at the Objective C and C++ http client code and noticed
>> that it does not supply the Connection: close header. This means that
>> webservers keep the connection alive assuming its a persistent
>> connection. This slows down client side request processing
>> significantly and also wastes server resources. I created issues 1153
>> and 1154 for c++ and objective c respectively it would be great to
>> have then in the next release.
>>
>> I also noticed a similar issue in java although I am not sure whether
>> the the change is needed in java or whether underlying layers take
>> care of it.
>>
>> --regards
>> Usman Ismail
>>
>

Re: HttpClient Connection close bugs

[Usman Ismail]

As far as I can tell for c++ and objective c we are not actually using
persistent http, i.e. we do not reuse open connections. Hence not
setting the close header just means it takes longer to close the
connection. In the long run I agree  we should explore use of
persistent http connections as well as user specified headers.

--usman

On Tue, Apr 26, 2011 at 2:12 PM, Seth Hitchings  wrote:
> Using keep-alive should improve performance, not degrade it. Adding
> Connection: close would significantly degrade performance, especially for
> HTTPS connections.
>
> In general, it would be great if all of the HTTP client transports exposed
> the ability to customize headers, so that an app could override defaults or
> add custom headers without modifying the client itself.
>
> Seth
>
> On Tue, Apr 26, 2011 at 10:43 AM, Usman Ismail <0x...@gmail.com> wrote:
>
>> Hi,
>>
>> I had a look at the Objective C and C++ http client code and noticed
>> that it does not supply the Connection: close header. This means that
>> webservers keep the connection alive assuming its a persistent
>> connection. This slows down client side request processing
>> significantly and also wastes server resources. I created issues 1153
>> and 1154 for c++ and objective c respectively it would be great to
>> have then in the next release.
>>
>> I also noticed a similar issue in java although I am not sure whether
>> the the change is needed in java or whether underlying layers take
>> care of it.
>>
>> --regards
>> Usman Ismail
>>
>

Re: HttpClient Connection close bugs

[Seth Hitchings]

Using keep-alive should improve performance, not degrade it. Adding
Connection: close would significantly degrade performance, especially for
HTTPS connections.

In general, it would be great if all of the HTTP client transports exposed
the ability to customize headers, so that an app could override defaults or
add custom headers without modifying the client itself.

Seth

On Tue, Apr 26, 2011 at 10:43 AM, Usman Ismail <0x...@gmail.com> wrote:

> Hi,
>
> I had a look at the Objective C and C++ http client code and noticed
> that it does not supply the Connection: close header. This means that
> webservers keep the connection alive assuming its a persistent
> connection. This slows down client side request processing
> significantly and also wastes server resources. I created issues 1153
> and 1154 for c++ and objective c respectively it would be great to
> have then in the next release.
>
> I also noticed a similar issue in java although I am not sure whether
> the the change is needed in java or whether underlying layers take
> care of it.
>
> --regards
> Usman Ismail
>

[jira] [Commented] (THRIFT-1155) Remove log4j dependency from java client

[Hudson (JIRA)]

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

Hudson commented on THRIFT-1155:


Integrated in Thrift #137 (See 
[https://builds.apache.org/hudson/job/Thrift/137/])
THRIFT-1155: Remove log4j dependency from java client
Client: java

Removed dependency for slf4j-log4j for pom and broke requirements for testing. 
This fixes those requirements and restores the build.


> Remove log4j dependency from java client
> 
>
> Key: THRIFT-1155
> URL: https://issues.apache.org/jira/browse/THRIFT-1155
> Project: Thrift
>  Issue Type: Improvement
>Affects Versions: 0.6.1, 0.7
>Reporter: Jake Farrell
>Assignee: Jake Farrell
> Fix For: 0.7
>
>
> Remove unnecessary dependency on log4j from java client

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Jenkins build is back to normal : Thrift #137

[Apache Jenkins Server]

See 

Build failed in Jenkins: Thrift #136

[Apache Jenkins Server]

See 

Changes:

[jfarrell] Thrift-1155: Remove log4j dependency from java client.
Client: java

slf4j-log4j should not be included with the pom since it is not required for 
the client. Any logger supported by slf4j can be used.

--
[...truncated 1697 lines...]
gcc -DHAVE_CONFIG_H -I. -I../../..  -g -Wall -I../src -I/usr/include/glib-2.0 
-I/usr/lib/glib-2.0/include  -MT testsimpleserver.o -MD -MP -MF 
.deps/testsimpleserver.Tpo -c -o testsimpleserver.o testsimpleserver.c
mv -f .deps/testsimpleserver.Tpo .deps/testsimpleserver.Po
/bin/bash ../../../libtool --tag=CC   --mode=link gcc   -lglib-2.0   -pthread 
-lgobject-2.0 -lgthread-2.0 -lrt -lglib-2.0 -o testsimpleserver 
testsimpleserver.o ../libthrift_c_glib_la-thrift_protocol.o 
../libthrift_c_glib_la-thrift_transport.o 
../libthrift_c_glib_la-thrift_transport_factory.o 
../libthrift_c_glib_la-thrift_processor.o 
../libthrift_c_glib_la-thrift_protocol_factory.o 
../libthrift_c_glib_la-thrift_binary_protocol.o 
../libthrift_c_glib_la-thrift_binary_protocol_factory.o 
../libthrift_c_glib_la-thrift_socket.o 
../libthrift_c_glib_la-thrift_server_transport.o 
../libthrift_c_glib_la-thrift_server_socket.o 
../libthrift_c_glib_la-thrift_server.o -lssl -lrt -lpthread 
libtool: link: gcc -pthread -o testsimpleserver testsimpleserver.o 
../libthrift_c_glib_la-thrift_protocol.o 
../libthrift_c_glib_la-thrift_transport.o 
../libthrift_c_glib_la-thrift_transport_factory.o 
../libthrift_c_glib_la-thrift_processor.o 
../libthrift_c_glib_la-thrift_protocol_factory.o 
../libthrift_c_glib_la-thrift_binary_protocol.o 
../libthrift_c_glib_la-thrift_binary_protocol_factory.o 
../libthrift_c_glib_la-thrift_socket.o 
../libthrift_c_glib_la-thrift_server_transport.o 
../libthrift_c_glib_la-thrift_server_socket.o 
../libthrift_c_glib_la-thrift_server.o  /usr/lib/libgobject-2.0.so 
/usr/lib/libgthread-2.0.so /usr/lib/libglib-2.0.so -lssl -lrt -lpthread -pthread
gcc -DHAVE_CONFIG_H -I. -I../../..  -g -Wall -I../src -I/usr/include/glib-2.0 
-I/usr/lib/glib-2.0/include  -MT testdebugproto.o -MD -MP -MF 
.deps/testdebugproto.Tpo -c -o testdebugproto.o testdebugproto.c
testdebugproto.c: In function 'test_debug_proto':
testdebugproto.c:78: warning: 'return' with a value, in function returning void
mv -f .deps/testdebugproto.Tpo .deps/testdebugproto.Po
/bin/bash ../../../libtool --tag=CC   --mode=link gcc   -lglib-2.0   -pthread 
-lgobject-2.0 -lgthread-2.0 -lrt -lglib-2.0 -o testdebugproto 
testdebugproto.o libtestgenc.la -lssl -lrt -lpthread 
libtool: link: gcc -pthread -o .libs/testdebugproto testdebugproto.o  
./.libs/libtestgenc.a /usr/lib/libgobject-2.0.so /usr/lib/libgthread-2.0.so 
/usr/lib/libglib-2.0.so 

 -lssl -lrt -lpthread -pthread
gcc -DHAVE_CONFIG_H -I. -I../../..  -g -Wall -I../src -I/usr/include/glib-2.0 
-I/usr/lib/glib-2.0/include  -MT testoptionalrequired.o -MD -MP -MF 
.deps/testoptionalrequired.Tpo -c -o testoptionalrequired.o 
testoptionalrequired.c
testoptionalrequired.c: In function 't_test_old_school_read':
gen-c_glib/t_test_optional_required_test_types.c:122: warning: '_elem0' may be 
used uninitialized in this function
mv -f .deps/testoptionalrequired.Tpo .deps/testoptionalrequired.Po
/bin/bash ../../../libtool --tag=CC   --mode=link gcc   -lglib-2.0   -pthread 
-lgobject-2.0 -lgthread-2.0 -lrt -lglib-2.0 -o testoptionalrequired 
testoptionalrequired.o ../libthrift_c_glib_la-thrift_protocol.o 
../libthrift_c_glib_la-thrift_transport.o libtestgenc.la -lssl -lrt -lpthread 
libtool: link: gcc -pthread -o .libs/testoptionalrequired 
testoptionalrequired.o ../libthrift_c_glib_la-thrift_protocol.o 
../libthrift_c_glib_la-thrift_transport.o  ./.libs/libtestgenc.a 
/usr/lib/libgobject-2.0.so /usr/lib/libgthread-2.0.so /usr/lib/libglib-2.0.so 

 -lssl -lrt -lpthread -pthread
gcc -DHAVE_CONFIG_H -I. -I../../..  -g -Wall -I../src -I/usr/include/glib-2.0 
-I/usr/lib/glib-2.0/include  -MT testthrifttest.o -MD -MP -MF 
.deps/testthrifttest.Tpo -c -o testthrifttest.o testthrifttest.c
testthrifttest.c: In function 'main':
testthrifttest.c:25: warning: passing argument 2 of 'g_test_add_func' from 
incompatible pointer type
/usr/include/glib-2.0/glib/gtestutils.h:101: note: expected 'void (*)(void)' 
but argument is of type 'void (*)(const int)'
mv -f .deps/testthrifttest.Tpo .deps/testthrifttest.Po
/bin/bash ../../../libtool --tag=CC   --mode=link gcc   -lglib-2.0   -pthread 
-lgobject-2.0 -lgthread-2.0 -lrt -lglib-2.0 -o testthrifttest 
testthrifttest.o libtestgenc.la -lssl -lrt -lpthread 
libtool: link: gcc -pthread -o .libs/testthrifttest testthrifttest.o  
./.libs/libtestgenc.a /usr/lib/libgobject-2.0.so /usr/lib/libgthread-2.0.so 
/usr/lib/libglib-2.0.so 

HttpClient Connection close bugs

[Usman Ismail]

Hi,

I had a look at the Objective C and C++ http client code and noticed
that it does not supply the Connection: close header. This means that
webservers keep the connection alive assuming its a persistent
connection. This slows down client side request processing
significantly and also wastes server resources. I created issues 1153
and 1154 for c++ and objective c respectively it would be great to
have then in the next release.

I also noticed a similar issue in java although I am not sure whether
the the change is needed in java or whether underlying layers take
care of it.

--regards
Usman Ismail

[jira] [Closed] (THRIFT-1155) Remove log4j dependency from java client

[Jake Farrell (JIRA)]

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

Jake Farrell closed THRIFT-1155.


   Resolution: Fixed
Fix Version/s: 0.7

Removed slf4j-log4j dependency in the java build.xml. Any app using the client 
can now decide on which logger to use. 

> Remove log4j dependency from java client
> 
>
> Key: THRIFT-1155
> URL: https://issues.apache.org/jira/browse/THRIFT-1155
> Project: Thrift
>  Issue Type: Improvement
>Affects Versions: 0.6.1, 0.7
>Reporter: Jake Farrell
>Assignee: Jake Farrell
> Fix For: 0.7
>
>
> Remove unnecessary dependency on log4j from java client

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

A little fix in configure.ac

[Maksim A. Boyko]

Hi,

--- configure.ac(revision 1096713)
+++ configure.ac(working copy)
@@ -102,7 +102,7 @@
 have_cpp=no
 if test "$with_cpp" = "yes";  then
   AX_BOOST_BASE([1.33.1])
-  if test "x$succeeded" == "xyes" ; then
+  if test "x$succeeded" = "xyes" ; then
 have_cpp="yes"
   fi

-- 
Best regards, Maksim A. Boyko

[jira] [Created] (THRIFT-1156) Bug with Base 64 coding in TBase64Utils

[JIRA]

Bug with Base 64 coding in TBase64Utils
---

 Key: THRIFT-1156
 URL: https://issues.apache.org/jira/browse/THRIFT-1156
 Project: Thrift
  Issue Type: Bug
  Components: Java - Library
Affects Versions: 0.6
 Environment: Java SE, Android
Reporter: Głowka Rafał


There are some problems with coding byte[] when values are less that 0.

The example code :
public static void main(String[] args) 
{
byte[] data = new byte[256];
byte[] data2 = new byte[512];
for (int i = 0; i < 512; i++)
data2[i] = 0;
for (byte b = -128; b < 127; b++)
data[b + 128] = b;

int len = 256;
int off = 0;
int off2 = 0;
while (len >= 3) {
// Encode 3 bytes at a time
TBase64Utils.encode(data, off, 3, data2, off2);
off += 3;
off2 += 4;
len -= 3;
}
if (len > 0) {
// Encode remainder
TBase64Utils.encode(data, off, len, data2, off2);
}

len = 256;
off = 0;
off2 = 0;
while (len >= 3) {
// Encode 3 bytes at a time
TBase64Utils.decode(data2, off2, 4, data, off);
off += 3;
len -= 3;
off2 += 4;
}
if (len > 0) {
// Encode remainder
TBase64Utils.decode(data2, off2, len, data, off);
}

for (byte b = -128; b < 127; b++)
System.out.println("should be : " + (b) + " is : " + 
data[b + 128]);
}


The results : 
...
should be : -18 is : -18
should be : -17 is : -18
should be : -16 is : -1
should be : -15 is : -15
should be : -14 is : -15
should be : -13 is : -14
should be : -12 is : -12
should be : -11 is : -12
should be : -10 is : -11
should be : -9 is : -9
should be : -8 is : -5
should be : -7 is : -8
should be : -6 is : -6
should be : -5 is : -6
should be : -4 is : -5
should be : -3 is : -3
should be : -2 is : -3
should be : -1 is : -1
should be : 0 is : 0
should be : 1 is : 1
...



--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira