[jira] [Reopened] (THRIFT-1558) Named Pipe and Anonymous Pipe transport for Windows

2012-10-04 Thread Jake Farrell (JIRA)

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

Jake Farrell reopened THRIFT-1558:
--


> Named Pipe and Anonymous Pipe transport for Windows
> ---
>
> Key: THRIFT-1558
> URL: https://issues.apache.org/jira/browse/THRIFT-1558
> Project: Thrift
>  Issue Type: New Feature
>  Components: C++ - Library
>Affects Versions: 0.9
> Environment: Microsoft Windows / Visual Studio
>Reporter: Peace C
>Assignee: Roger Meier
>  Labels: anonymous, named, pipe, thrift, transport
> Attachments: Pipe_snippets.cpp, 
> Thrift-1558_xplatform_pipe_6-5-2012.patch, 
> Thrift_Named_Pipe_Transport_Windows.patch, Thrift_transport_sample.patch
>
>
> This patch adds named & anonymous pipe transport for Windows. The new classes 
> do not affect *NIX builds. We've been using this code on Windows & OSX for 6 
> months and I'm fairly confident in it. It has not been hammered by automated 
> tests and I welcome stress testing to wring out any bugs.
> The TPipe and TPipeServer classes are generally modeled after TSocket and 
> TSocketServer. The server of course uses TPipeServer to set up the server 
> side then instantiates TPipe for communications. The client instantiates 
> TPipe transport for connection to the server.
> Here are some code snippet examples from functions we've built. Variables 
> such as 'pipename' are passed in to the functions. Error handling has been 
> omitted.
> //---
> //  Server 
> //---
> #ifdef _WIN32
>   pipename = ".\\pipe\\" + pipename;
>   boost::shared_ptr transport(new TPipeServer(pipename, 
> 1024, NumThreads)); //Named pipe
> #else  //Mac, *NIX
>   unlink(pipename.c_str());
>   boost::shared_ptr transport(new 
> TServerSocket(pipename));
> #endif
>   boost::shared_ptr server;
>   boost::shared_ptr handler(new MyHandler());
>   boost::shared_ptr processor(new MyProcessor(handler));
>   boost::shared_ptr tfactory(new 
> TBufferedTransportFactory());
>   boost::shared_ptr pfactory(new 
> TBinaryProtocolFactory());
>   if(NumThreads <= 1)
>   {   //Single-threaded server
>   server.reset(new TSimpleServer(processor, transport, tfactory, 
> pfactory));
>   }
>   else
>   {   //Multi-threaded server
>   boost::shared_ptr threadManager = 
> ThreadManager::newSimpleThreadManager(NumThreads);
>   boost::shared_ptr threadFactory = 
> boost::shared_ptr(new PlatformThreadFactory());
>   threadManager->threadFactory(threadFactory);
>   threadManager->start();
>   server.reset(new TThreadPoolServer(processor, transport, 
> tfactory, pfactory, threadManager));
>   }
>   printf("Starting the 'server'...\n");
>   server->serve();
>   printf("done.\n");
> //---
> //  Client 
> //---
> #ifdef _WIN32
>   pipename = ".\\pipe\\" + pipename;
>   boost::shared_ptr pipe(new TPipe(pipename));
>   transport.reset(new TBufferedTransport(pipe));
> #else  //Mac, *nix
>   boost::shared_ptr socket(new TSocket(pipename));
>   transport.reset(new TBufferedTransport(socket));
> #endif
>   boost::shared_ptr protocol(new TBinaryProtocol(transport));
>   client.reset(new MyClient(protocol));

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (THRIFT-1558) Named Pipe and Anonymous Pipe transport for Windows

2012-10-04 Thread Peace C (JIRA)

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

Peace C commented on THRIFT-1558:
-

Jens - thanks for catching this. Please replace the following in 
TCreateAnonPipe:

  InitializeSecurityDescriptor(&sd,SECURITY_DESCRIPTOR_REVISION);
  SetSecurityDescriptorDacl(&sd, true, NULL, false);
  sa.lpSecurityDescriptor = &sd;
  sa.lpSecurityDescriptor = NULL;

with

  &sd = NULL;
  InitializeSecurityDescriptor(&sd,SECURITY_DESCRIPTOR_REVISION);
  SetSecurityDescriptorDacl(&sd, true, NULL, false);
  sa.lpSecurityDescriptor = &sd;


If this works, would you mind creating a patch and attaching to this issue? I'm 
hoping the fix can still make it into Thrift 0.9.

> Named Pipe and Anonymous Pipe transport for Windows
> ---
>
> Key: THRIFT-1558
> URL: https://issues.apache.org/jira/browse/THRIFT-1558
> Project: Thrift
>  Issue Type: New Feature
>  Components: C++ - Library
>Affects Versions: 0.9
> Environment: Microsoft Windows / Visual Studio
>Reporter: Peace C
>Assignee: Roger Meier
>  Labels: anonymous, named, pipe, thrift, transport
> Attachments: Pipe_snippets.cpp, 
> Thrift-1558_xplatform_pipe_6-5-2012.patch, 
> Thrift_Named_Pipe_Transport_Windows.patch, Thrift_transport_sample.patch
>
>
> This patch adds named & anonymous pipe transport for Windows. The new classes 
> do not affect *NIX builds. We've been using this code on Windows & OSX for 6 
> months and I'm fairly confident in it. It has not been hammered by automated 
> tests and I welcome stress testing to wring out any bugs.
> The TPipe and TPipeServer classes are generally modeled after TSocket and 
> TSocketServer. The server of course uses TPipeServer to set up the server 
> side then instantiates TPipe for communications. The client instantiates 
> TPipe transport for connection to the server.
> Here are some code snippet examples from functions we've built. Variables 
> such as 'pipename' are passed in to the functions. Error handling has been 
> omitted.
> //---
> //  Server 
> //---
> #ifdef _WIN32
>   pipename = ".\\pipe\\" + pipename;
>   boost::shared_ptr transport(new TPipeServer(pipename, 
> 1024, NumThreads)); //Named pipe
> #else  //Mac, *NIX
>   unlink(pipename.c_str());
>   boost::shared_ptr transport(new 
> TServerSocket(pipename));
> #endif
>   boost::shared_ptr server;
>   boost::shared_ptr handler(new MyHandler());
>   boost::shared_ptr processor(new MyProcessor(handler));
>   boost::shared_ptr tfactory(new 
> TBufferedTransportFactory());
>   boost::shared_ptr pfactory(new 
> TBinaryProtocolFactory());
>   if(NumThreads <= 1)
>   {   //Single-threaded server
>   server.reset(new TSimpleServer(processor, transport, tfactory, 
> pfactory));
>   }
>   else
>   {   //Multi-threaded server
>   boost::shared_ptr threadManager = 
> ThreadManager::newSimpleThreadManager(NumThreads);
>   boost::shared_ptr threadFactory = 
> boost::shared_ptr(new PlatformThreadFactory());
>   threadManager->threadFactory(threadFactory);
>   threadManager->start();
>   server.reset(new TThreadPoolServer(processor, transport, 
> tfactory, pfactory, threadManager));
>   }
>   printf("Starting the 'server'...\n");
>   server->serve();
>   printf("done.\n");
> //---
> //  Client 
> //---
> #ifdef _WIN32
>   pipename = ".\\pipe\\" + pipename;
>   boost::shared_ptr pipe(new TPipe(pipename));
>   transport.reset(new TBufferedTransport(pipe));
> #else  //Mac, *nix
>   boost::shared_ptr socket(new TSocket(pipename));
>   transport.reset(new TBufferedTransport(socket));
> #endif
>   boost::shared_ptr protocol(new TBinaryProtocol(transport));
>   client.reset(new MyClient(protocol));

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (THRIFT-1670) Incompatibilities between different versions of a Thrift interface

2012-10-04 Thread Hudson (JIRA)

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

Hudson commented on THRIFT-1670:


Integrated in Thrift #544 (See [https://builds.apache.org/job/Thrift/544/])
Thrift-1710: Minor issues in test cases code
Client: delphi
Patch: Jens Geyer

The patch for THRIFT-1670 left some minor issues open. These are hereby fixed.
- incorrect search paths in uses clause
- unused variable in ReadResponse()
- incorrectly formatted comment in IDL (Revision 1394339)

 Result = FAILURE
jfarrell : http://svn.apache.org/viewvc/?view=rev&rev=1394339
Files : 
* /thrift/trunk/lib/delphi/test/skip/idl/skiptest_version_1.thrift
* /thrift/trunk/lib/delphi/test/skip/idl/skiptest_version_2.thrift
* /thrift/trunk/lib/delphi/test/skip/skiptest_version1.dpr
* /thrift/trunk/lib/delphi/test/skip/skiptest_version1.dproj
* /thrift/trunk/lib/delphi/test/skip/skiptest_version2.dpr
* /thrift/trunk/lib/delphi/test/skip/skiptest_version2.dproj


> Incompatibilities between different versions of a Thrift interface
> --
>
> Key: THRIFT-1670
> URL: https://issues.apache.org/jira/browse/THRIFT-1670
> Project: Thrift
>  Issue Type: Bug
>  Components: Delphi - Library
>Affects Versions: 0.8, 0.9
>Reporter: Jens Geyer
>Assignee: Jens Geyer
>  Labels: bug, compatibility
> Fix For: 0.9
>
> Attachments: 
> THRIFT-1670_part_1_Incompatibilities_between_different_versions_of_a_Thrift_interface.patch,
>  
> THRIFT-1670_part_2_Incompatibilities_between_different_versions_of_a_Thrift_interface.patch
>
>
> The method TProtocolUtil.Skip() lacks implementation, which leads to 
> exceptions after unknown message members are found by the generated 
> deserialisation code.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (THRIFT-1709) Warning "Bitwise-or operator used on a sign-extended operand; consider casting to a smaller unsigned type first" in TBinaryProtocol.cs at ReadInt64()

2012-10-04 Thread Hudson (JIRA)

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

Hudson commented on THRIFT-1709:


Integrated in Thrift #544 (See [https://builds.apache.org/job/Thrift/544/])
Thrift-1709:Warning "Bitwise-or operator used on a sign-extended operand; 
consider casting to a smaller unsigned type first" in TBinaryProtocol.cs at 
ReadInt64()
Client: csharp
Patch: Jens Geyer

Fixes warning at the byte shift operations due to a missing cast at the 
bitwise-or. (Revision 1394338)

 Result = FAILURE

> Warning "Bitwise-or operator used on a sign-extended operand; consider 
> casting to a smaller unsigned type first" in TBinaryProtocol.cs at 
> ReadInt64() 
> --
>
> Key: THRIFT-1709
> URL: https://issues.apache.org/jira/browse/THRIFT-1709
> Project: Thrift
>  Issue Type: Bug
>  Components: C# - Library
>Affects Versions: 0.8, 0.9
> Environment: Windows + Silverlight + WP7
>Reporter: Jens Geyer
>Assignee: Jens Geyer
>Priority: Trivial
> Fix For: 0.9
>
> Attachments: 
> THIFT-1709_Bitwise_or_operator_used_on_a_signextended_operand_at_ReadInt64().patch
>
>
> There's an annoying warning at the byte shift operations due to a missing 
> cast at the bitwise-or. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (THRIFT-1710) Minor issues in test case code

2012-10-04 Thread Hudson (JIRA)

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

Hudson commented on THRIFT-1710:


Integrated in Thrift #544 (See [https://builds.apache.org/job/Thrift/544/])
Thrift-1710: Minor issues in test cases code
Client: delphi
Patch: Jens Geyer

The patch for THRIFT-1670 left some minor issues open. These are hereby fixed.
- incorrect search paths in uses clause
- unused variable in ReadResponse()
- incorrectly formatted comment in IDL (Revision 1394339)

 Result = FAILURE

> Minor issues in test case code
> --
>
> Key: THRIFT-1710
> URL: https://issues.apache.org/jira/browse/THRIFT-1710
> Project: Thrift
>  Issue Type: Bug
>  Components: Delphi - Library
>Affects Versions: 0.9
>Reporter: Jens Geyer
>Assignee: Jens Geyer
> Fix For: 0.9
>
> Attachments: THRIFT-1710_Minor_issues_in_test_case_code.patch
>
>
> The patch for THRIFT-1670 left some minor issues open. These are hereby fixed.
> * incorrect search paths in uses clause
> * unused variable in ReadResponse()
> * incorrectly formatted comment in IDL

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


Build failed in Jenkins: Thrift #544

2012-10-04 Thread Apache Jenkins Server
See 

Changes:

[jfarrell] Thrift-1710: Minor issues in test cases code
Client: delphi
Patch: Jens Geyer

The patch for THRIFT-1670 left some minor issues open. These are hereby fixed.
- incorrect search paths in uses clause
- unused variable in ReadResponse()
- incorrectly formatted comment in IDL

[jfarrell] Thrift-1709:Warning "Bitwise-or operator used on a sign-extended 
operand; consider casting to a smaller unsigned type first" in 
TBinaryProtocol.cs at ReadInt64()
Client: csharp
Patch: Jens Geyer

Fixes warning at the byte shift operations due to a missing cast at the 
bitwise-or.

--
[...truncated 1424 lines...]
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../.. -g -Wall -W -Werror -Isrc -I 
src/thrift -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include 
-MT libthrift_c_glib_la-thrift_simple_server.lo -MD -MP -MF 
.deps/libthrift_c_glib_la-thrift_simple_server.Tpo -c 
src/thrift/server/thrift_simple_server.c -o 
libthrift_c_glib_la-thrift_simple_server.o >/dev/null 2>&1
mv -f .deps/libthrift_c_glib_la-thrift_simple_server.Tpo 
.deps/libthrift_c_glib_la-thrift_simple_server.Plo
/bin/bash ../../libtool --tag=CC   --mode=link gcc -g -Wall -W -Werror -Isrc -I 
src/thrift -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include 
 -o libthrift_c_glib.la -rpath /usr/local/lib libthrift_c_glib_la-thrift.lo 
libthrift_c_glib_la-thrift_struct.lo 
libthrift_c_glib_la-thrift_application_exception.lo 
libthrift_c_glib_la-thrift_processor.lo libthrift_c_glib_la-thrift_protocol.lo 
libthrift_c_glib_la-thrift_protocol_factory.lo 
libthrift_c_glib_la-thrift_binary_protocol.lo 
libthrift_c_glib_la-thrift_binary_protocol_factory.lo 
libthrift_c_glib_la-thrift_transport.lo 
libthrift_c_glib_la-thrift_transport_factory.lo 
libthrift_c_glib_la-thrift_socket.lo 
libthrift_c_glib_la-thrift_server_transport.lo 
libthrift_c_glib_la-thrift_server_socket.lo 
libthrift_c_glib_la-thrift_buffered_transport.lo 
libthrift_c_glib_la-thrift_framed_transport.lo 
libthrift_c_glib_la-thrift_memory_buffer.lo 
libthrift_c_glib_la-thrift_server.lo 
libthrift_c_glib_la-thrift_simple_server.lo  -lssl -lcrypto -lrt -lpthread 
libtool: link: gcc -shared  -fPIC -DPIC  .libs/libthrift_c_glib_la-thrift.o 
.libs/libthrift_c_glib_la-thrift_struct.o 
.libs/libthrift_c_glib_la-thrift_application_exception.o 
.libs/libthrift_c_glib_la-thrift_processor.o 
.libs/libthrift_c_glib_la-thrift_protocol.o 
.libs/libthrift_c_glib_la-thrift_protocol_factory.o 
.libs/libthrift_c_glib_la-thrift_binary_protocol.o 
.libs/libthrift_c_glib_la-thrift_binary_protocol_factory.o 
.libs/libthrift_c_glib_la-thrift_transport.o 
.libs/libthrift_c_glib_la-thrift_transport_factory.o 
.libs/libthrift_c_glib_la-thrift_socket.o 
.libs/libthrift_c_glib_la-thrift_server_transport.o 
.libs/libthrift_c_glib_la-thrift_server_socket.o 
.libs/libthrift_c_glib_la-thrift_buffered_transport.o 
.libs/libthrift_c_glib_la-thrift_framed_transport.o 
.libs/libthrift_c_glib_la-thrift_memory_buffer.o 
.libs/libthrift_c_glib_la-thrift_server.o 
.libs/libthrift_c_glib_la-thrift_simple_server.o   -lssl -lcrypto -lrt 
-lpthread-Wl,-soname -Wl,libthrift_c_glib.so.0 -o 
.libs/libthrift_c_glib.so.0.0.0
libtool: link: (cd ".libs" && rm -f "libthrift_c_glib.so.0" && ln -s 
"libthrift_c_glib.so.0.0.0" "libthrift_c_glib.so.0")
libtool: link: (cd ".libs" && rm -f "libthrift_c_glib.so" && ln -s 
"libthrift_c_glib.so.0.0.0" "libthrift_c_glib.so")
libtool: link: ar cru .libs/libthrift_c_glib.a  libthrift_c_glib_la-thrift.o 
libthrift_c_glib_la-thrift_struct.o 
libthrift_c_glib_la-thrift_application_exception.o 
libthrift_c_glib_la-thrift_processor.o libthrift_c_glib_la-thrift_protocol.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_transport.o 
libthrift_c_glib_la-thrift_transport_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_buffered_transport.o 
libthrift_c_glib_la-thrift_framed_transport.o 
libthrift_c_glib_la-thrift_memory_buffer.o libthrift_c_glib_la-thrift_server.o 
libthrift_c_glib_la-thrift_simple_server.o
libtool: link: ranlib .libs/libthrift_c_glib.a
libtool: link: ( cd ".libs" && rm -f "libthrift_c_glib.la" && ln -s 
"../libthrift_c_glib.la" "libthrift_c_glib.la" )
make[4]: Leaving directory 
`
Making all in test
make[4]: Entering directory 
`
make[5]: Entering directory 
`
make[5]: Nothing to be done for `all-am'.
make[5]: Leaving directory 
`
make[4]: Leaving directory 
`

Jenkins build is back to normal : Thrift-cpp #452

2012-10-04 Thread Apache Jenkins Server
See 



Build failed in Jenkins: Thrift-Debian-Packages #300

2012-10-04 Thread Apache Jenkins Server
See 

Changes:

[jfarrell] Thrift-1710: Minor issues in test cases code
Client: delphi
Patch: Jens Geyer

The patch for THRIFT-1670 left some minor issues open. These are hereby fixed.
- incorrect search paths in uses clause
- unused variable in ReadResponse()
- incorrectly formatted comment in IDL

[jfarrell] Thrift-1709:Warning "Bitwise-or operator used on a sign-extended 
operand; consider casting to a smaller unsigned type first" in 
TBinaryProtocol.cs at ReadInt64()
Client: csharp
Patch: Jens Geyer

Fixes warning at the byte shift operations due to a missing cast at the 
bitwise-or.

--
[...truncated 1477 lines...]
copying src/transport/THttpClient.py -> 
build/lib.linux-x86_64-2.6-pydebug/thrift/transport
copying src/transport/TTwisted.py -> 
build/lib.linux-x86_64-2.6-pydebug/thrift/transport
copying src/transport/__init__.py -> 
build/lib.linux-x86_64-2.6-pydebug/thrift/transport
creating build/lib.linux-x86_64-2.6-pydebug/thrift/server
copying src/server/THttpServer.py -> 
build/lib.linux-x86_64-2.6-pydebug/thrift/server
copying src/server/TServer.py -> 
build/lib.linux-x86_64-2.6-pydebug/thrift/server
copying src/server/TNonblockingServer.py -> 
build/lib.linux-x86_64-2.6-pydebug/thrift/server
copying src/server/TProcessPoolServer.py -> 
build/lib.linux-x86_64-2.6-pydebug/thrift/server
copying src/server/__init__.py -> 
build/lib.linux-x86_64-2.6-pydebug/thrift/server
running build_ext
building 'thrift.protocol.fastbinary' extension
creating build/temp.linux-x86_64-2.6-pydebug
creating build/temp.linux-x86_64-2.6-pydebug/src
creating build/temp.linux-x86_64-2.6-pydebug/src/protocol
gcc -pthread -fno-strict-aliasing -g -Wall -Wstrict-prototypes -g -O2 -fPIC 
-I/usr/include/python2.6_d -c src/protocol/fastbinary.c -o 
build/temp.linux-x86_64-2.6-pydebug/src/protocol/fastbinary.o
gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-Bsymbolic-functions 
-g -O2 build/temp.linux-x86_64-2.6-pydebug/src/protocol/fastbinary.o -o 
build/lib.linux-x86_64-2.6-pydebug/thrift/protocol/fastbinary_d.so
[33973 refs]
# PHP
cd 
/x1/jenkins/jenkins-slave/workspace/Thrift-Debian-Packages/thrift/lib/php/src/ext/thrift_protocol
 && \
phpize && \
./configure && make
Configuring for:
PHP Api Version: 20090626
Zend Module Api No:  20090626
Zend Extension Api No:   220090626
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for a sed that does not truncate output... /bin/sed
checking for cc... cc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether cc accepts -g... yes
checking for cc option to accept ISO C89... none needed
checking how to run the C preprocessor... cc -E
checking for icc... no
checking for suncc... no
checking whether cc understands -c and -o together... yes
checking for system library directory... lib
checking if compiler supports -R... no
checking if compiler supports -Wl,-rpath,... yes
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking for PHP prefix... /usr
checking for PHP includes... -I/usr/include/php5 -I/usr/include/php5/main 
-I/usr/include/php5/TSRM -I/usr/include/php5/Zend -I/usr/include/php5/ext 
-I/usr/include/php5/ext/date/lib
checking for PHP extension directory... /usr/lib/php5/20090626
checking for PHP installed headers prefix... /usr/include/php5
checking if debug is enabled... no
checking if zts is enabled... no
checking for re2c... no
configure: WARNING: You will need re2c 0.13.4 or later if you want to 
regenerate PHP parsers.
checking for gawk... no
checking for nawk... nawk
checking if nawk is broken... no
checking whether to enable the thrift_protocol extension... yes, shared
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking how to run the C++ preprocessor... g++ -E
checking for a sed that does not truncate output... (cached) /bin/sed
checking for fgrep... /bin/grep -F
checking for ld used by cc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 3458764513820540925
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recogn

[jira] [Closed] (THRIFT-1710) Minor issues in test case code

2012-10-04 Thread Jake Farrell (JIRA)

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

Jake Farrell closed THRIFT-1710.


Resolution: Fixed

committed

> Minor issues in test case code
> --
>
> Key: THRIFT-1710
> URL: https://issues.apache.org/jira/browse/THRIFT-1710
> Project: Thrift
>  Issue Type: Bug
>  Components: Delphi - Library
>Affects Versions: 0.9
>Reporter: Jens Geyer
>Assignee: Jens Geyer
> Fix For: 0.9
>
> Attachments: THRIFT-1710_Minor_issues_in_test_case_code.patch
>
>
> The patch for THRIFT-1670 left some minor issues open. These are hereby fixed.
> * incorrect search paths in uses clause
> * unused variable in ReadResponse()
> * incorrectly formatted comment in IDL

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Closed] (THRIFT-1709) Warning "Bitwise-or operator used on a sign-extended operand; consider casting to a smaller unsigned type first" in TBinaryProtocol.cs at ReadInt64()

2012-10-04 Thread Jake Farrell (JIRA)

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

Jake Farrell closed THRIFT-1709.


Resolution: Fixed
  Assignee: Jens Geyer

committed

> Warning "Bitwise-or operator used on a sign-extended operand; consider 
> casting to a smaller unsigned type first" in TBinaryProtocol.cs at 
> ReadInt64() 
> --
>
> Key: THRIFT-1709
> URL: https://issues.apache.org/jira/browse/THRIFT-1709
> Project: Thrift
>  Issue Type: Bug
>  Components: C# - Library
>Affects Versions: 0.8, 0.9
> Environment: Windows + Silverlight + WP7
>Reporter: Jens Geyer
>Assignee: Jens Geyer
>Priority: Trivial
> Fix For: 0.9
>
> Attachments: 
> THIFT-1709_Bitwise_or_operator_used_on_a_signextended_operand_at_ReadInt64().patch
>
>
> There's an annoying warning at the byte shift operations due to a missing 
> cast at the bitwise-or. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (THRIFT-1708) Add event handlers for processor events

2012-10-04 Thread Jake Farrell (JIRA)

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

Jake Farrell commented on THRIFT-1708:
--

Andrew, this is a really great addition. I am reviewing the patch now and 
really like what i've seen of it so far. Would love to see the addition of this 
for C++, Python and any other languages as well, can you please add your other 
patches to this ticket broken out per language. Thanks

> Add event handlers for processor events
> ---
>
> Key: THRIFT-1708
> URL: https://issues.apache.org/jira/browse/THRIFT-1708
> Project: Thrift
>  Issue Type: New Feature
>  Components: Java - Library
>Affects Versions: 0.9
> Environment: all
>Reporter: Andrew Cox
>Assignee: Andrew Cox
>Priority: Minor
> Fix For: 0.9
>
> Attachments: thrift-1708-processor-event-handlers.patch
>
>
> Integrates some code we've been using (here at facebook) to add event 
> handlers that can handle processor events with the server event handlers in 
> apache thrift.
> Processor events include: preRead (before reading arguments), postRead (after 
> reading arguments), preWrite (before writing results), postWrite (after 
> writing results), and processorError (when a non-IDL exception is thrown as a 
> result of an error handling the request). The processor handler is given the 
> method name and input and output protocol that will be used to process the 
> request, and can inspect arguments on postRead, and results on pre/postWrite 
> events.
> This change also enables event handlers for non-blocking servers.
> Some unit tests are included to exercise the new processor event handlers, 
> and demonstrate how they can connect with server event handlers.
> It also fixes a minor bug I found while testing, where FrameBuffers on 
> non-blocking servers could have been close()'d more than once.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (THRIFT-1558) Named Pipe and Anonymous Pipe transport for Windows

2012-10-04 Thread Jens Geyer (JIRA)

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

Jens Geyer commented on THRIFT-1558:


Hi Peace,

I have a problem with CreateAnonPipe()

{code}
  sa.lpSecurityDescriptor = &sd;
  sa.lpSecurityDescriptor = NULL;
{code}

One of these lines is obsolete. Which one is it?


> Named Pipe and Anonymous Pipe transport for Windows
> ---
>
> Key: THRIFT-1558
> URL: https://issues.apache.org/jira/browse/THRIFT-1558
> Project: Thrift
>  Issue Type: New Feature
>  Components: C++ - Library
>Affects Versions: 0.9
> Environment: Microsoft Windows / Visual Studio
>Reporter: Peace C
>Assignee: Roger Meier
>  Labels: anonymous, named, pipe, thrift, transport
> Attachments: Pipe_snippets.cpp, 
> Thrift-1558_xplatform_pipe_6-5-2012.patch, 
> Thrift_Named_Pipe_Transport_Windows.patch, Thrift_transport_sample.patch
>
>
> This patch adds named & anonymous pipe transport for Windows. The new classes 
> do not affect *NIX builds. We've been using this code on Windows & OSX for 6 
> months and I'm fairly confident in it. It has not been hammered by automated 
> tests and I welcome stress testing to wring out any bugs.
> The TPipe and TPipeServer classes are generally modeled after TSocket and 
> TSocketServer. The server of course uses TPipeServer to set up the server 
> side then instantiates TPipe for communications. The client instantiates 
> TPipe transport for connection to the server.
> Here are some code snippet examples from functions we've built. Variables 
> such as 'pipename' are passed in to the functions. Error handling has been 
> omitted.
> //---
> //  Server 
> //---
> #ifdef _WIN32
>   pipename = ".\\pipe\\" + pipename;
>   boost::shared_ptr transport(new TPipeServer(pipename, 
> 1024, NumThreads)); //Named pipe
> #else  //Mac, *NIX
>   unlink(pipename.c_str());
>   boost::shared_ptr transport(new 
> TServerSocket(pipename));
> #endif
>   boost::shared_ptr server;
>   boost::shared_ptr handler(new MyHandler());
>   boost::shared_ptr processor(new MyProcessor(handler));
>   boost::shared_ptr tfactory(new 
> TBufferedTransportFactory());
>   boost::shared_ptr pfactory(new 
> TBinaryProtocolFactory());
>   if(NumThreads <= 1)
>   {   //Single-threaded server
>   server.reset(new TSimpleServer(processor, transport, tfactory, 
> pfactory));
>   }
>   else
>   {   //Multi-threaded server
>   boost::shared_ptr threadManager = 
> ThreadManager::newSimpleThreadManager(NumThreads);
>   boost::shared_ptr threadFactory = 
> boost::shared_ptr(new PlatformThreadFactory());
>   threadManager->threadFactory(threadFactory);
>   threadManager->start();
>   server.reset(new TThreadPoolServer(processor, transport, 
> tfactory, pfactory, threadManager));
>   }
>   printf("Starting the 'server'...\n");
>   server->serve();
>   printf("done.\n");
> //---
> //  Client 
> //---
> #ifdef _WIN32
>   pipename = ".\\pipe\\" + pipename;
>   boost::shared_ptr pipe(new TPipe(pipename));
>   transport.reset(new TBufferedTransport(pipe));
> #else  //Mac, *nix
>   boost::shared_ptr socket(new TSocket(pipename));
>   transport.reset(new TBufferedTransport(socket));
> #endif
>   boost::shared_ptr protocol(new TBinaryProtocol(transport));
>   client.reset(new MyClient(protocol));

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (THRIFT-1690) Sockets and Pipe Handles truncated on Win64

2012-10-04 Thread Roger Meier (JIRA)

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

Roger Meier commented on THRIFT-1690:
-

one patch per issue made acording to 
http://thrift.apache.org/docs/HowToContribute
would be great, diff's made within a subtree are not that easy to handle.
simplification, that's all...

thanks for the patch!
roger




> Sockets and Pipe Handles truncated on Win64
> ---
>
> Key: THRIFT-1690
> URL: https://issues.apache.org/jira/browse/THRIFT-1690
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
>Affects Versions: 0.9
> Environment: 64-bit Windows
>Reporter: Ben Craig
>Assignee: Roger Meier
> Attachments: libthrift_pipe_size.patch, libthrift_warning_purge.patch
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> On 64-bit Windows, "int" is a 32-bit value.  SOCKET and HANDLE are 64-bit.
> All of the files dealing with sockets in thrift use "int" as the type of a 
> socket, as this is the idiomatic way to handle sockets on POSIX systems.  For 
> portability, a SOCKET typedef is probably needed.
> For the Pipe Server and Pipe Transport, HANDLEs are cast to ints to store as 
> member variables for some reason (maybe to avoid #including  in a 
> header?).
> Both of these situations can result in invalid handles being used (and valid 
> handles being leaked) when the system is under load.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (THRIFT-1710) Minor issues in test case code

2012-10-04 Thread Jens Geyer (JIRA)

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

Jens Geyer updated THRIFT-1710:
---

Attachment: THRIFT-1710_Minor_issues_in_test_case_code.patch

Additioanlly. there are two *.dproj files to be deleted (please don't confuse 
*.dproj with *.dpr): 
* skiptest_version1.dproj
* skiptest_version2.dproj

Thank you.

> Minor issues in test case code
> --
>
> Key: THRIFT-1710
> URL: https://issues.apache.org/jira/browse/THRIFT-1710
> Project: Thrift
>  Issue Type: Bug
>  Components: Delphi - Library
>Affects Versions: 0.9
>Reporter: Jens Geyer
>Assignee: Jens Geyer
> Fix For: 0.9
>
> Attachments: THRIFT-1710_Minor_issues_in_test_case_code.patch
>
>
> The patch for THRIFT-1670 left some minor issues open. These are hereby fixed.
> * incorrect search paths in uses clause
> * unused variable in ReadResponse()
> * incorrectly formatted comment in IDL

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (THRIFT-1690) Sockets and Pipe Handles truncated on Win64

2012-10-04 Thread Ben Craig (JIRA)

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

Ben Craig commented on THRIFT-1690:
---

Roger,
I will be glad to better follow process in the future.  I'm not sure what I 
messed up with my last submission though.  What should I do better in the 
future?  Single .patch for the entire fix?  Remove the commentary in the .patch 
file?

> Sockets and Pipe Handles truncated on Win64
> ---
>
> Key: THRIFT-1690
> URL: https://issues.apache.org/jira/browse/THRIFT-1690
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
>Affects Versions: 0.9
> Environment: 64-bit Windows
>Reporter: Ben Craig
>Assignee: Roger Meier
> Attachments: libthrift_pipe_size.patch, libthrift_warning_purge.patch
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> On 64-bit Windows, "int" is a 32-bit value.  SOCKET and HANDLE are 64-bit.
> All of the files dealing with sockets in thrift use "int" as the type of a 
> socket, as this is the idiomatic way to handle sockets on POSIX systems.  For 
> portability, a SOCKET typedef is probably needed.
> For the Pipe Server and Pipe Transport, HANDLEs are cast to ints to store as 
> member variables for some reason (maybe to avoid #including  in a 
> header?).
> Both of these situations can result in invalid handles being used (and valid 
> handles being leaked) when the system is under load.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Created] (THRIFT-1711) \TException with blank code and message

2012-10-04 Thread Till Klampaeckel (JIRA)
Till Klampaeckel created THRIFT-1711:


 Summary: \TException with blank code and message
 Key: THRIFT-1711
 URL: https://issues.apache.org/jira/browse/THRIFT-1711
 Project: Thrift
  Issue Type: Bug
  Components: PHP - Library
Reporter: Till Klampaeckel


When a {{\TException}} is thrown, all kind of custom variables are assigned to 
the exception class in the {{__construct}}. However, the default {{code}} and 
{{message}} of the exception class are not populated.

Is it possible to fix this? Currently this presents an edge-case in exception 
handling.

Cross-referencing this issue on PHPUnit here:
https://github.com/sebastianbergmann/phpunit/pull/679

I could (maybe :-)) work on a patch – however I am not sure if a patch PHP 
userland (aka  {{Thrift.php}}) or if that code is generated and I would have to 
patch something else.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Created] (THRIFT-1710) Minor issues in test case code

2012-10-04 Thread Jens Geyer (JIRA)
Jens Geyer created THRIFT-1710:
--

 Summary: Minor issues in test case code
 Key: THRIFT-1710
 URL: https://issues.apache.org/jira/browse/THRIFT-1710
 Project: Thrift
  Issue Type: Bug
  Components: Delphi - Library
Affects Versions: 0.9
Reporter: Jens Geyer
Assignee: Jens Geyer
 Fix For: 0.9


The patch for THRIFT-1670 left some minor issues open. These are hereby fixed.

* incorrect search paths in uses clause
* unused variable in ReadResponse()
* incorrectly formatted comment in IDL

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (THRIFT-1709) Warning "Bitwise-or operator used on a sign-extended operand; consider casting to a smaller unsigned type first" in TBinaryProtocol.cs at ReadInt64()

2012-10-04 Thread Jens Geyer (JIRA)

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

Jens Geyer updated THRIFT-1709:
---

Attachment: 
THIFT-1709_Bitwise_or_operator_used_on_a_signextended_operand_at_ReadInt64().patch

> Warning "Bitwise-or operator used on a sign-extended operand; consider 
> casting to a smaller unsigned type first" in TBinaryProtocol.cs at 
> ReadInt64() 
> --
>
> Key: THRIFT-1709
> URL: https://issues.apache.org/jira/browse/THRIFT-1709
> Project: Thrift
>  Issue Type: Bug
>  Components: C# - Library
>Affects Versions: 0.8, 0.9
> Environment: Windows + Silverlight + WP7
>Reporter: Jens Geyer
> Fix For: 0.9
>
> Attachments: 
> THIFT-1709_Bitwise_or_operator_used_on_a_signextended_operand_at_ReadInt64().patch
>
>
> There's an annoying warning at the byte shift operations due to a missing 
> cast at the bitwise-or. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Updated] (THRIFT-1709) Warning "Bitwise-or operator used on a sign-extended operand; consider casting to a smaller unsigned type first" in TBinaryProtocol.cs at ReadInt64()

2012-10-04 Thread Jens Geyer (JIRA)

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

Jens Geyer updated THRIFT-1709:
---

Priority: Trivial  (was: Major)

> Warning "Bitwise-or operator used on a sign-extended operand; consider 
> casting to a smaller unsigned type first" in TBinaryProtocol.cs at 
> ReadInt64() 
> --
>
> Key: THRIFT-1709
> URL: https://issues.apache.org/jira/browse/THRIFT-1709
> Project: Thrift
>  Issue Type: Bug
>  Components: C# - Library
>Affects Versions: 0.8, 0.9
> Environment: Windows + Silverlight + WP7
>Reporter: Jens Geyer
>Priority: Trivial
> Fix For: 0.9
>
> Attachments: 
> THIFT-1709_Bitwise_or_operator_used_on_a_signextended_operand_at_ReadInt64().patch
>
>
> There's an annoying warning at the byte shift operations due to a missing 
> cast at the bitwise-or. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Created] (THRIFT-1709) Warning "Bitwise-or operator used on a sign-extended operand; consider casting to a smaller unsigned type first" in TBinaryProtocol.cs at ReadInt64()

2012-10-04 Thread Jens Geyer (JIRA)
Jens Geyer created THRIFT-1709:
--

 Summary: Warning "Bitwise-or operator used on a sign-extended 
operand; consider casting to a smaller unsigned type first" in 
TBinaryProtocol.cs at ReadInt64() 
 Key: THRIFT-1709
 URL: https://issues.apache.org/jira/browse/THRIFT-1709
 Project: Thrift
  Issue Type: Bug
  Components: C# - Library
Affects Versions: 0.8, 0.9
 Environment: Windows + Silverlight + WP7
Reporter: Jens Geyer
 Fix For: 0.9


There's an annoying warning at the byte shift operations due to a missing cast 
at the bitwise-or. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Comment Edited] (THRIFT-1700) Number overflow in ReadFrame.

2012-10-04 Thread Jens Geyer (JIRA)

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

Jens Geyer edited comment on THRIFT-1700 at 10/5/12 6:12 AM:
-

{quote}
We use C# for client. Seems like thrift don't generates async wrappers for sync 
methods when using C#. So we made our hand-made task-based wrappers. 
{quote}

Have you checked the switches for C#? Thrift indeed supports async/await and 
Task<>.

  was (Author: jensg):
{We use C# for client. Seems like thrift don't generates async wrappers for 
sync methods when using C#. So we made our hand-made task-based wrappers. }

Have you checked the switches for C#? Thrift indeed supports async/await and 
Task<>.
  
> Number overflow in ReadFrame.
> -
>
> Key: THRIFT-1700
> URL: https://issues.apache.org/jira/browse/THRIFT-1700
> Project: Thrift
>  Issue Type: Bug
>  Components: C# - Library
>Affects Versions: 0.8
>Reporter: Alexey
>
> private void ReadFrame()
> {
>   byte[] i32rd = new byte[header_size];
>   transport.ReadAll(i32rd, 0, header_size);
>   int size =
>   ((i32rd[0] & 0xff) << 24) |
>   ((i32rd[1] & 0xff) << 16) |
>   ((i32rd[2] & 0xff) <<  8) |
>   ((i32rd[3] & 0xff));
>   byte[] buff = new byte[size];
>   transport.ReadAll(buff, 0, size);
>   readBuffer = new MemoryStream(buff);
> }
> Here, when calculating size, number overflow throws sometimes.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (THRIFT-1700) Number overflow in ReadFrame.

2012-10-04 Thread Jens Geyer (JIRA)

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

Jens Geyer commented on THRIFT-1700:


{We use C# for client. Seems like thrift don't generates async wrappers for 
sync methods when using C#. So we made our hand-made task-based wrappers. }

Have you checked the switches for C#? Thrift indeed supports async/await and 
Task<>.

> Number overflow in ReadFrame.
> -
>
> Key: THRIFT-1700
> URL: https://issues.apache.org/jira/browse/THRIFT-1700
> Project: Thrift
>  Issue Type: Bug
>  Components: C# - Library
>Affects Versions: 0.8
>Reporter: Alexey
>
> private void ReadFrame()
> {
>   byte[] i32rd = new byte[header_size];
>   transport.ReadAll(i32rd, 0, header_size);
>   int size =
>   ((i32rd[0] & 0xff) << 24) |
>   ((i32rd[1] & 0xff) << 16) |
>   ((i32rd[2] & 0xff) <<  8) |
>   ((i32rd[3] & 0xff));
>   byte[] buff = new byte[size];
>   transport.ReadAll(buff, 0, size);
>   readBuffer = new MemoryStream(buff);
> }
> Here, when calculating size, number overflow throws sometimes.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (THRIFT-1690) Sockets and Pipe Handles truncated on Win64

2012-10-04 Thread Hudson (JIRA)

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

Hudson commented on THRIFT-1690:


Integrated in Thrift #543 (See [https://builds.apache.org/job/Thrift/543/])
THRIFT-1690 Sockets and Pipe Handles truncated on Win64
Patch: Ben Craig (Revision 1394182)

 Result = FAILURE
roger : http://svn.apache.org/viewvc/?view=rev&rev=1394182
Files : 
* /thrift/trunk/lib/cpp/src/thrift/concurrency/BoostMonitor.cpp
* /thrift/trunk/lib/cpp/src/thrift/concurrency/TimerManager.cpp
* /thrift/trunk/lib/cpp/src/thrift/concurrency/Util.cpp
* /thrift/trunk/lib/cpp/src/thrift/concurrency/Util.h
* /thrift/trunk/lib/cpp/src/thrift/protocol/TBinaryProtocol.tcc
* /thrift/trunk/lib/cpp/src/thrift/protocol/TDebugProtocol.cpp
* /thrift/trunk/lib/cpp/src/thrift/protocol/TDenseProtocol.cpp
* /thrift/trunk/lib/cpp/src/thrift/protocol/TJSONProtocol.cpp
* /thrift/trunk/lib/cpp/src/thrift/protocol/TProtocol.h
* /thrift/trunk/lib/cpp/src/thrift/server/TThreadPoolServer.cpp
* /thrift/trunk/lib/cpp/src/thrift/transport/TBufferTransports.cpp
* /thrift/trunk/lib/cpp/src/thrift/transport/TBufferTransports.h
* /thrift/trunk/lib/cpp/src/thrift/transport/TFDTransport.cpp
* /thrift/trunk/lib/cpp/src/thrift/transport/TFileTransport.cpp
* /thrift/trunk/lib/cpp/src/thrift/transport/TFileTransport.h
* /thrift/trunk/lib/cpp/src/thrift/transport/THttpClient.cpp
* /thrift/trunk/lib/cpp/src/thrift/transport/THttpServer.cpp
* /thrift/trunk/lib/cpp/src/thrift/transport/THttpTransport.cpp
* /thrift/trunk/lib/cpp/src/thrift/transport/TPipe.cpp
* /thrift/trunk/lib/cpp/src/thrift/transport/TPipe.h
* /thrift/trunk/lib/cpp/src/thrift/transport/TPipeServer.cpp
* /thrift/trunk/lib/cpp/src/thrift/transport/TPipeServer.h
* /thrift/trunk/lib/cpp/src/thrift/transport/TServerSocket.cpp
* /thrift/trunk/lib/cpp/src/thrift/transport/TServerSocket.h
* /thrift/trunk/lib/cpp/src/thrift/transport/TSocket.cpp
* /thrift/trunk/lib/cpp/src/thrift/transport/TSocket.h
* /thrift/trunk/lib/cpp/src/thrift/transport/TSocketPool.cpp
* /thrift/trunk/lib/cpp/src/thrift/transport/TSocketPool.h
* /thrift/trunk/lib/cpp/src/thrift/windows/SocketPair.cpp
* /thrift/trunk/lib/cpp/src/thrift/windows/SocketPair.h
* /thrift/trunk/lib/cpp/src/thrift/windows/StdAfx.h
* /thrift/trunk/lib/cpp/src/thrift/windows/WinFcntl.cpp
* /thrift/trunk/lib/cpp/src/thrift/windows/WinFcntl.h
* /thrift/trunk/lib/cpp/src/thrift/windows/config.h
* /thrift/trunk/lib/cpp/src/thrift/windows/force_inc.h


> Sockets and Pipe Handles truncated on Win64
> ---
>
> Key: THRIFT-1690
> URL: https://issues.apache.org/jira/browse/THRIFT-1690
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
>Affects Versions: 0.9
> Environment: 64-bit Windows
>Reporter: Ben Craig
>Assignee: Roger Meier
> Attachments: libthrift_pipe_size.patch, libthrift_warning_purge.patch
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> On 64-bit Windows, "int" is a 32-bit value.  SOCKET and HANDLE are 64-bit.
> All of the files dealing with sockets in thrift use "int" as the type of a 
> socket, as this is the idiomatic way to handle sockets on POSIX systems.  For 
> portability, a SOCKET typedef is probably needed.
> For the Pipe Server and Pipe Transport, HANDLEs are cast to ints to store as 
> member variables for some reason (maybe to avoid #including  in a 
> header?).
> Both of these situations can result in invalid handles being used (and valid 
> handles being leaked) when the system is under load.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


Build failed in Jenkins: Thrift #543

2012-10-04 Thread Apache Jenkins Server
See 

Changes:

[roger] add some ignores

[roger] THRIFT-1690 Sockets and Pipe Handles truncated on Win64
Patch: Ben Craig

--
[...truncated 2902 lines...]
/bin/bash ../../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. 
-I../..-g -Wall -W -Werror -Isrc -I src/thrift -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include-MT 
libthrift_c_glib_la-thrift_simple_server.lo -MD -MP -MF 
.deps/libthrift_c_glib_la-thrift_simple_server.Tpo -c -o 
libthrift_c_glib_la-thrift_simple_server.lo `test -f 
'src/thrift/server/thrift_simple_server.c' || echo 
'./'`src/thrift/server/thrift_simple_server.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../.. -g -Wall -W -Werror -Isrc -I 
src/thrift -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include 
-MT libthrift_c_glib_la-thrift_simple_server.lo -MD -MP -MF 
.deps/libthrift_c_glib_la-thrift_simple_server.Tpo -c 
src/thrift/server/thrift_simple_server.c  -fPIC -DPIC -o 
.libs/libthrift_c_glib_la-thrift_simple_server.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../.. -g -Wall -W -Werror -Isrc -I 
src/thrift -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include 
-MT libthrift_c_glib_la-thrift_simple_server.lo -MD -MP -MF 
.deps/libthrift_c_glib_la-thrift_simple_server.Tpo -c 
src/thrift/server/thrift_simple_server.c -o 
libthrift_c_glib_la-thrift_simple_server.o >/dev/null 2>&1
mv -f .deps/libthrift_c_glib_la-thrift_simple_server.Tpo 
.deps/libthrift_c_glib_la-thrift_simple_server.Plo
/bin/bash ../../libtool --tag=CC   --mode=link gcc -g -Wall -W -Werror -Isrc -I 
src/thrift -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include 
 -o libthrift_c_glib.la -rpath /usr/local/lib libthrift_c_glib_la-thrift.lo 
libthrift_c_glib_la-thrift_struct.lo 
libthrift_c_glib_la-thrift_application_exception.lo 
libthrift_c_glib_la-thrift_processor.lo libthrift_c_glib_la-thrift_protocol.lo 
libthrift_c_glib_la-thrift_protocol_factory.lo 
libthrift_c_glib_la-thrift_binary_protocol.lo 
libthrift_c_glib_la-thrift_binary_protocol_factory.lo 
libthrift_c_glib_la-thrift_transport.lo 
libthrift_c_glib_la-thrift_transport_factory.lo 
libthrift_c_glib_la-thrift_socket.lo 
libthrift_c_glib_la-thrift_server_transport.lo 
libthrift_c_glib_la-thrift_server_socket.lo 
libthrift_c_glib_la-thrift_buffered_transport.lo 
libthrift_c_glib_la-thrift_framed_transport.lo 
libthrift_c_glib_la-thrift_memory_buffer.lo 
libthrift_c_glib_la-thrift_server.lo 
libthrift_c_glib_la-thrift_simple_server.lo  -lssl -lcrypto -lrt -lpthread 
libtool: link: gcc -shared  -fPIC -DPIC  .libs/libthrift_c_glib_la-thrift.o 
.libs/libthrift_c_glib_la-thrift_struct.o 
.libs/libthrift_c_glib_la-thrift_application_exception.o 
.libs/libthrift_c_glib_la-thrift_processor.o 
.libs/libthrift_c_glib_la-thrift_protocol.o 
.libs/libthrift_c_glib_la-thrift_protocol_factory.o 
.libs/libthrift_c_glib_la-thrift_binary_protocol.o 
.libs/libthrift_c_glib_la-thrift_binary_protocol_factory.o 
.libs/libthrift_c_glib_la-thrift_transport.o 
.libs/libthrift_c_glib_la-thrift_transport_factory.o 
.libs/libthrift_c_glib_la-thrift_socket.o 
.libs/libthrift_c_glib_la-thrift_server_transport.o 
.libs/libthrift_c_glib_la-thrift_server_socket.o 
.libs/libthrift_c_glib_la-thrift_buffered_transport.o 
.libs/libthrift_c_glib_la-thrift_framed_transport.o 
.libs/libthrift_c_glib_la-thrift_memory_buffer.o 
.libs/libthrift_c_glib_la-thrift_server.o 
.libs/libthrift_c_glib_la-thrift_simple_server.o   -lssl -lcrypto -lrt 
-lpthread-Wl,-soname -Wl,libthrift_c_glib.so.0 -o 
.libs/libthrift_c_glib.so.0.0.0
libtool: link: (cd ".libs" && rm -f "libthrift_c_glib.so.0" && ln -s 
"libthrift_c_glib.so.0.0.0" "libthrift_c_glib.so.0")
libtool: link: (cd ".libs" && rm -f "libthrift_c_glib.so" && ln -s 
"libthrift_c_glib.so.0.0.0" "libthrift_c_glib.so")
libtool: link: ar cru .libs/libthrift_c_glib.a  libthrift_c_glib_la-thrift.o 
libthrift_c_glib_la-thrift_struct.o 
libthrift_c_glib_la-thrift_application_exception.o 
libthrift_c_glib_la-thrift_processor.o libthrift_c_glib_la-thrift_protocol.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_transport.o 
libthrift_c_glib_la-thrift_transport_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_buffered_transport.o 
libthrift_c_glib_la-thrift_framed_transport.o 
libthrift_c_glib_la-thrift_memory_buffer.o libthrift_c_glib_la-thrift_server.o 
libthrift_c_glib_la-thrift_simple_server.o
libtool: link: ranlib .libs/libthrift_c_glib.a
libtool: link: ( cd ".libs" && rm -f "libthrift_c_glib.la" && ln -s 
"../libthrift_c_glib.la" "libthrift_c_glib.la" )
make[4]: Leaving directory 
`

Build failed in Jenkins: Thrift-Debian-Packages #299

2012-10-04 Thread Apache Jenkins Server
See 

Changes:

[roger] add some ignores

[roger] THRIFT-1690 Sockets and Pipe Handles truncated on Win64
Patch: Ben Craig

--
[...truncated 133 lines...]
Deleting 

Deleting 

Deleting 

Deleting 

Deleting 

Deleting 

Deleting 

Deleting 

Deleting 

Deleting 

Deleting 

Deleting 

Deleting 

Deleting 

Deleting 

Deleting 

Deleting 

Deleting 

Deleting 

Deleting 

Deleting 

Deleting 

Deleting 

Deleting 

Deleting 

Deleting 

Deleting 

Deleting 

Deleting 

Deleting 

Deleting 

Deleting 

Deleting 

Deleting 

Deleting 

Deleting 

Deleting 

Deleting 

Deleting 

Deleting 

Deleting 

Deleting 

Deleting 

Deleting 

Deleting 

Deleting 

Deleting 

Deleting 

Build failed in Jenkins: Thrift-cpp #451

2012-10-04 Thread Apache Jenkins Server
See 

Changes:

[roger] add some ignores

[roger] THRIFT-1690 Sockets and Pipe Handles truncated on Win64
Patch: Ben Craig

--
[...truncated 1666 lines...]
checking for gomake... /usr/local/bin/gomake
checking for goinstall... /usr/local/bin/goinstall
checking for library containing strerror... none required
checking for an ANSI C-conforming const... yes
checking for inline... inline
checking for working volatile... yes
checking for stdbool.h that conforms to C99... yes
checking for _Bool... no
checking for ANSI C header files... (cached) yes
checking whether time.h and sys/time.h may both be included... yes
checking for sys/wait.h that is POSIX.1 compatible... yes
checking return type of signal handlers... void
checking arpa/inet.h usability... yes
checking arpa/inet.h presence... yes
checking for arpa/inet.h... yes
checking sys/param.h usability... yes
checking sys/param.h presence... yes
checking for sys/param.h... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking for inttypes.h... (cached) yes
checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking netdb.h usability... yes
checking netdb.h presence... yes
checking for netdb.h... yes
checking netinet/in.h usability... yes
checking netinet/in.h presence... yes
checking for netinet/in.h... yes
checking pthread.h usability... yes
checking pthread.h presence... yes
checking for pthread.h... yes
checking stddef.h usability... yes
checking stddef.h presence... yes
checking for stddef.h... yes
checking for stdlib.h... (cached) yes
checking sys/socket.h usability... yes
checking sys/socket.h presence... yes
checking for sys/socket.h... yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking sys/un.h usability... yes
checking sys/un.h presence... yes
checking for sys/un.h... yes
checking sys/poll.h usability... yes
checking sys/poll.h presence... yes
checking for sys/poll.h... yes
checking sys/resource.h usability... yes
checking sys/resource.h presence... yes
checking for sys/resource.h... yes
checking for unistd.h... (cached) yes
checking libintl.h usability... yes
checking libintl.h presence... yes
checking for libintl.h... yes
checking malloc.h usability... yes
checking malloc.h presence... yes
checking for malloc.h... yes
checking openssl/ssl.h usability... yes
checking openssl/ssl.h presence... yes
checking for openssl/ssl.h... yes
checking openssl/rand.h usability... yes
checking openssl/rand.h presence... yes
checking for openssl/rand.h... yes
checking openssl/x509v3.h usability... yes
checking openssl/x509v3.h presence... yes
checking for openssl/x509v3.h... yes
checking sched.h usability... yes
checking sched.h presence... yes
checking for sched.h... yes
checking for pthread_create in -lpthread... yes
checking for clock_gettime in -lrt... yes
checking for setsockopt in -lsocket... no
checking for BN_init in -lcrypto... yes
checking for SSL_ctrl in -lssl... yes
checking for int16_t... yes
checking for int32_t... yes
checking for int64_t... yes
checking for int8_t... yes
checking for mode_t... yes
checking for off_t... yes
checking for size_t... yes
checking for ssize_t... yes
checking for uint16_t... yes
checking for uint32_t... yes
checking for uint64_t... yes
checking for uint8_t... yes
checking for ptrdiff_t... yes
checking whether struct tm is in sys/time.h or time.h... time.h
checking whether AI_ADDRCONFIG is declared... yes
checking for working alloca.h... yes
checking for alloca... yes
checking for pid_t... yes
checking vfork.h usability... no
checking vfork.h presence... no
checking for vfork.h... no
checking for fork... yes
checking for vfork... yes
checking for working fork... yes
checking for working vfork... (cached) yes
checking for stdlib.h... (cached) yes
checking for GNU libc compatible malloc... yes
checking for working memcmp... yes
checking for stdlib.h... (cached) yes
checking for GNU libc compatible realloc... yes
checking sys/select.h usability... yes
checking sys/select.h presence... yes
checking for sys/select.h... yes
checking for sys/socket.h... (cached) yes
checking types of arguments for select... int,fd_set *,struct timeval *
checking whether lstat correctly handles trailing slash... yes
checking whether stat accepts an empty string... no
checking whether strerror_r is declared... yes
checking for strerror_r... yes
checking whether strerror_r returns char *... yes
checking for strftime... yes
checking for vprintf... yes
checking for _doprnt... no
checking for strtoul... yes
checking for bzero... yes
checking for ftruncate... yes
checking for gethostbyname... yes
checking for gettimeofday... yes
checking for memmove... yes
checking for memset... yes
checking for mkdir... yes
checking for realpath... yes
checking for select... yes
checking for socket... yes
checking f

[jira] [Resolved] (THRIFT-1690) Sockets and Pipe Handles truncated on Win64

2012-10-04 Thread Roger Meier (JIRA)

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

Roger Meier resolved THRIFT-1690.
-

Resolution: Fixed

Thanks Ben, committed!

Could you please create future patches according to
http://thrift.apache.org/docs/HowToContribute/

=> this simplifies and speeds up review/commit phase.

thanks
roger

> Sockets and Pipe Handles truncated on Win64
> ---
>
> Key: THRIFT-1690
> URL: https://issues.apache.org/jira/browse/THRIFT-1690
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
>Affects Versions: 0.9
> Environment: 64-bit Windows
>Reporter: Ben Craig
>Assignee: Roger Meier
> Attachments: libthrift_pipe_size.patch, libthrift_warning_purge.patch
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> On 64-bit Windows, "int" is a 32-bit value.  SOCKET and HANDLE are 64-bit.
> All of the files dealing with sockets in thrift use "int" as the type of a 
> socket, as this is the idiomatic way to handle sockets on POSIX systems.  For 
> portability, a SOCKET typedef is probably needed.
> For the Pipe Server and Pipe Transport, HANDLEs are cast to ints to store as 
> member variables for some reason (maybe to avoid #including  in a 
> header?).
> Both of these situations can result in invalid handles being used (and valid 
> handles being leaked) when the system is under load.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (THRIFT-1695) allow warning-free compilation in VS 2012 and GNU 4.6

2012-10-04 Thread Roger Meier (JIRA)

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

Roger Meier commented on THRIFT-1695:
-

please recreate patch according to
http://thrift.apache.org/docs/HowToContribute/

thanks!
;-r

> allow warning-free compilation in VS 2012 and GNU 4.6
> -
>
> Key: THRIFT-1695
> URL: https://issues.apache.org/jira/browse/THRIFT-1695
> Project: Thrift
>  Issue Type: Improvement
>  Components: C++ - Library
>Affects Versions: 0.9
> Environment: Windows and any Unix
>Reporter: James K. Lowden
>  Labels: patch
> Fix For: 1.0
>
> Attachments: compiler_is_dir.patch, compiler_switch_default.patch, 
> compiler_unused_locals.patch, libthrift_warning_purge.patch, 
> platform_direct.patch, thrift.warningfree.pax.gz
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> The patches allow the current trunk of Thrift C++ to
> build without warnings in Visual Studio and GNU gcc.  
> I introduce THRIFT_SAFE_CAST in Thrift.h, which tests narrowing
> conversions for fit.  Would-be overflows throw std::runtime_error.  
> Some functions have been modified or overloaded to allow size_t
> parameters.  SOCKET is dealt with intelligently.  
> IMO every public thrift function should have a form accepting normal
> types -- including e.g. short, int, long, and size_t -- and apply casts
> as necessary.  In particular size_t is important because std
> constainers have size() members that usually return something like
> size_t.  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Assigned] (THRIFT-1690) Sockets and Pipe Handles truncated on Win64

2012-10-04 Thread Roger Meier (JIRA)

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

Roger Meier reassigned THRIFT-1690:
---

Assignee: Roger Meier

> Sockets and Pipe Handles truncated on Win64
> ---
>
> Key: THRIFT-1690
> URL: https://issues.apache.org/jira/browse/THRIFT-1690
> Project: Thrift
>  Issue Type: Bug
>  Components: C++ - Library
>Affects Versions: 0.9
> Environment: 64-bit Windows
>Reporter: Ben Craig
>Assignee: Roger Meier
> Attachments: libthrift_pipe_size.patch, libthrift_warning_purge.patch
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> On 64-bit Windows, "int" is a 32-bit value.  SOCKET and HANDLE are 64-bit.
> All of the files dealing with sockets in thrift use "int" as the type of a 
> socket, as this is the idiomatic way to handle sockets on POSIX systems.  For 
> portability, a SOCKET typedef is probably needed.
> For the Pipe Server and Pipe Transport, HANDLEs are cast to ints to store as 
> member variables for some reason (maybe to avoid #including  in a 
> header?).
> Both of these situations can result in invalid handles being used (and valid 
> handles being leaked) when the system is under load.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Comment Edited] (THRIFT-1700) Number overflow in ReadFrame.

2012-10-04 Thread Maxim Korobov (JIRA)

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

Maxim Korobov edited comment on THRIFT-1700 at 10/4/12 11:33 PM:
-

BTW, does thrift generator knows that byte in C# is [Unsigned 8-bit 
integer|http://msdn.microsoft.com/en-us/library/5bdb6693%28v=vs.71%29.aspx], 
not [8-bit signed two's complement 
integer|http://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html]
 like in Java.

  was (Author: maximkorobov):
BTW, did thrift generator knows that byte in C# is [Unsigned 8-bit 
integer|http://msdn.microsoft.com/en-us/library/5bdb6693%28v=vs.71%29.aspx], 
not [8-bit signed two's complement 
integer|http://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html]
 like in Java.
  
> Number overflow in ReadFrame.
> -
>
> Key: THRIFT-1700
> URL: https://issues.apache.org/jira/browse/THRIFT-1700
> Project: Thrift
>  Issue Type: Bug
>  Components: C# - Library
>Affects Versions: 0.8
>Reporter: Alexey
>
> private void ReadFrame()
> {
>   byte[] i32rd = new byte[header_size];
>   transport.ReadAll(i32rd, 0, header_size);
>   int size =
>   ((i32rd[0] & 0xff) << 24) |
>   ((i32rd[1] & 0xff) << 16) |
>   ((i32rd[2] & 0xff) <<  8) |
>   ((i32rd[3] & 0xff));
>   byte[] buff = new byte[size];
>   transport.ReadAll(buff, 0, size);
>   readBuffer = new MemoryStream(buff);
> }
> Here, when calculating size, number overflow throws sometimes.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Comment Edited] (THRIFT-1700) Number overflow in ReadFrame.

2012-10-04 Thread Maxim Korobov (JIRA)

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

Maxim Korobov edited comment on THRIFT-1700 at 10/4/12 11:23 PM:
-

??I finally got to see your code...??

We use C# for client. Seems like thrift don't generates async wrappers for sync 
methods when using C#. So we made our hand-made task-based wrappers. Here they 
are:

{code:title=C#}
public void GetStream (GetStreamAction action, Action  
onSuccess = null,
   Action  onError = null)
{
factory.StartNew (() => {
try {
ConnectIfNeed ();

var result = Client.getStream (action);

if (onSuccess != null)
onSuccess (result);

return result;
} catch (Exception e) {
if (onError != null)
onError (e);
return null;
}
} 
);
}
{code}

{code:title=thrift}
struct GetStreamAction {
1: string authKey
2: commons.StreamId streamId
3: optional commons.Cursor cursor
}

commons.StreamContent getStream( 1 : GetStreamAction action ) throws (1: 
BackendException ex)
{code}

??It seems like your frame is just too big :)??
??You'd have to change ReadAll as well in order to be able to read a uint or 
you will get a negative value when casing it back to int.??

I will try it out.

??Anyway, it would "only" allow you to read another 2 million bytes, is it 
enough for you???

2 billions, maybe?

??did you try with the buffered transport? and what is the other target 
language?  actually it should NOT send a size bigger than int.Max!??

I will try it out. Our colleagues at server-side uses Java+Scala.

  was (Author: maximkorobov):
??I finally got to see your code...??

We use C# for client. Seems like thrift don't generates async wrappers for sync 
methods when using C#. So we made our hand-made task-based wrappers. Here it is:

{code:title=C#}
public void GetStream (GetStreamAction action, Action  
onSuccess = null,
   Action  onError = null)
{
factory.StartNew (() => {
try {
ConnectIfNeed ();

var result = Client.getStream (action);

if (onSuccess != null)
onSuccess (result);

return result;
} catch (Exception e) {
if (onError != null)
onError (e);
return null;
}
} 
);
}
{code}

{code:title=thrift}
struct GetStreamAction {
1: string authKey
2: commons.StreamId streamId
3: optional commons.Cursor cursor
}

commons.StreamContent getStream( 1 : GetStreamAction action ) throws (1: 
BackendException ex)
{code}

??It seems like your frame is just too big :)??
??You'd have to change ReadAll as well in order to be able to read a uint or 
you will get a negative value when casing it back to int.??

I will try it out.

??Anyway, it would "only" allow you to read another 2 million bytes, is it 
enough for you???

2 billions, maybe?

??did you try with the buffered transport? and what is the other target 
language?  actually it should NOT send a size bigger than int.Max!??

I will try it out. Our colleagues at server-side uses Java+Scala.
  
> Number overflow in ReadFrame.
> -
>
> Key: THRIFT-1700
> URL: https://issues.apache.org/jira/browse/THRIFT-1700
> Project: Thrift
>  Issue Type: Bug
>  Components: C# - Library
>Affects Versions: 0.8
>Reporter: Alexey
>
> private void ReadFrame()
> {
>   byte[] i32rd = new byte[header_size];
>   transport.ReadAll(i32rd, 0, header_size);
>   int size =
>   ((i32rd[0] & 0xff) << 24) |
>   ((i32rd[1] & 0xff) << 16) |
>   ((i32rd[2] & 0xff) <<  8) |
>   ((i32rd[3] & 0xff));
>   byte[] buff = new byte[size];
>   transport.ReadAll(buff, 0, size);
>   readBuffer = new MemoryStream(buff);
> }
> Here, when calculating size, number overflow throws sometimes.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (THRIFT-1700) Number overflow in ReadFrame.

2012-10-04 Thread Maxim Korobov (JIRA)

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

Maxim Korobov commented on THRIFT-1700:
---

BTW, did thrift generator knows that byte in C# is [Unsigned 8-bit 
integer|http://msdn.microsoft.com/en-us/library/5bdb6693%28v=vs.71%29.aspx], 
not [8-bit signed two's complement 
integer|http://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html]
 like in Java.

> Number overflow in ReadFrame.
> -
>
> Key: THRIFT-1700
> URL: https://issues.apache.org/jira/browse/THRIFT-1700
> Project: Thrift
>  Issue Type: Bug
>  Components: C# - Library
>Affects Versions: 0.8
>Reporter: Alexey
>
> private void ReadFrame()
> {
>   byte[] i32rd = new byte[header_size];
>   transport.ReadAll(i32rd, 0, header_size);
>   int size =
>   ((i32rd[0] & 0xff) << 24) |
>   ((i32rd[1] & 0xff) << 16) |
>   ((i32rd[2] & 0xff) <<  8) |
>   ((i32rd[3] & 0xff));
>   byte[] buff = new byte[size];
>   transport.ReadAll(buff, 0, size);
>   readBuffer = new MemoryStream(buff);
> }
> Here, when calculating size, number overflow throws sometimes.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] [Commented] (THRIFT-1700) Number overflow in ReadFrame.

2012-10-04 Thread Maxim Korobov (JIRA)

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

Maxim Korobov commented on THRIFT-1700:
---

??I finally got to see your code...??

We use C# for client. Seems like thrift don't generates async wrappers for sync 
methods when using C#. So we made our hand-made task-based wrappers. Here it is:

{code:title=C#}
public void GetStream (GetStreamAction action, Action  
onSuccess = null,
   Action  onError = null)
{
factory.StartNew (() => {
try {
ConnectIfNeed ();

var result = Client.getStream (action);

if (onSuccess != null)
onSuccess (result);

return result;
} catch (Exception e) {
if (onError != null)
onError (e);
return null;
}
} 
);
}
{code}

{code:title=thrift}
struct GetStreamAction {
1: string authKey
2: commons.StreamId streamId
3: optional commons.Cursor cursor
}

commons.StreamContent getStream( 1 : GetStreamAction action ) throws (1: 
BackendException ex)
{code}

??It seems like your frame is just too big :)??
??You'd have to change ReadAll as well in order to be able to read a uint or 
you will get a negative value when casing it back to int.??

I will try it out.

??Anyway, it would "only" allow you to read another 2 million bytes, is it 
enough for you???

2 billions, maybe?

??did you try with the buffered transport? and what is the other target 
language?  actually it should NOT send a size bigger than int.Max!??

I will try it out. Our colleagues at server-side uses Java+Scala.

> Number overflow in ReadFrame.
> -
>
> Key: THRIFT-1700
> URL: https://issues.apache.org/jira/browse/THRIFT-1700
> Project: Thrift
>  Issue Type: Bug
>  Components: C# - Library
>Affects Versions: 0.8
>Reporter: Alexey
>
> private void ReadFrame()
> {
>   byte[] i32rd = new byte[header_size];
>   transport.ReadAll(i32rd, 0, header_size);
>   int size =
>   ((i32rd[0] & 0xff) << 24) |
>   ((i32rd[1] & 0xff) << 16) |
>   ((i32rd[2] & 0xff) <<  8) |
>   ((i32rd[3] & 0xff));
>   byte[] buff = new byte[size];
>   transport.ReadAll(buff, 0, size);
>   readBuffer = new MemoryStream(buff);
> }
> Here, when calculating size, number overflow throws sometimes.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira