Thrift
  1. Thrift
  2. THRIFT-1123

Patch to compile Thrift server and client for vc++ 9.0 and 10.0

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Trivial Trivial
    • Resolution: Duplicate
    • Affects Version/s: None
    • Fix Version/s: 0.8
    • Component/s: C++ - Library
    • Labels:
      None
    • Environment:

      Windows XP 32bit, vc++ 9.0, 10.0

    • Patch Info:
      Patch Available

      Description

      Extension of THRIFT-1031 patch published by James Dickson

      This patch is intended to provide Thrift C/C++ functionality on WIN32 platforms.
      The implementation is built on top of the patch "Patch to compile Thrift for vc++ 9.0 and 10.0" by James Dickson published as THRIFT-1031. I just used this code and ported more Thrieft C/C++ to WIN32 and added them to original VC projects created in THRIFT-1031.

      I express my gratitude to Mr. Dickson as his post gave me the roadmap how to do the additional changes, that I hope, would be useful for the rest of the community too.

      Besides client capabilities enabled in THRIFT-1031, the library can now be used for building Thrift servers and using concurrency features. The dir/file structure from THRIFT-1031 and usage of Config.h header for providing support for both WIN32 and *NIX remains.

      The implementation was tested briefly on MSVC2008, MSVC2010 and Ubuntu, communicating between C/C++ clients and servers and Java clients and servers. As the author needs all of this functionality for one of his projects, the testing and debugging will continue.

      Revision 1086435 from March, 28, 2011. was used for development and creation of patch, but it should be possible to apply it on current trunk revision as long as no changes are made to patched files in trunk.

        Issue Links

          Activity

          Hide
          Roger Meier added a comment -

          duplicate of THRIFT-1031

          please create a new ticket for additional features not within trunk

          Show
          Roger Meier added a comment - duplicate of THRIFT-1031 please create a new ticket for additional features not within trunk
          Hide
          Deepak Muley added a comment -

          Thanks a lot @Dragan, This worked great for my test app.

          Show
          Deepak Muley added a comment - Thanks a lot @Dragan, This worked great for my test app.
          Hide
          Dragan Okiljevic added a comment -

          @Deepak
          Hi, it looks like I made a typo while porting TServerSocket to WIN32.

          The argument for send function in void TServerSocket::interrupt() should be &byte instead of byte:

          if (-1 == send(intSock1_, reinterpret_cast<const buffer_unit_t *>(&byte), sizeof(int8_t), 0)) { ...

          It should work after this change.

          Show
          Dragan Okiljevic added a comment - @Deepak Hi, it looks like I made a typo while porting TServerSocket to WIN32. The argument for send function in void TServerSocket::interrupt() should be &byte instead of byte: if (-1 == send(intSock1_, reinterpret_cast<const buffer_unit_t *>(&byte), sizeof(int8_t), 0)) { ... It should work after this change.
          Hide
          Deepak Muley added a comment -

          Hello All,

          I am facing one interesting issue on windows while shutting down the windows server. I am using thrift patches 1031 and 1123 with 0.6.0 version of thrift.

          here is the sequence of events:

          After running server, I see that it is hosting the server as follows:

          netstat -a -n -o | find "9090"
          TCP 0.0.0.0:9090 0.0.0.0:0 LISTENING 2752
          TCP [::]:9090 [::]:0 LISTENING 2752

          After calling my server’s fb303 shutdown call from a client,

          Server prints following but does not come out of the loop:
          Thrift: Tue Aug 30 10:31:24 2011 TServerSocket::interrupt() send() errno = 0

          netstat -a -n -o | find "9090"
          TCP 0.0.0.0:9090 0.0.0.0:0 LISTENING 2752
          TCP [::]:9090 [::]:0 LISTENING 2752
          TCP [::1]:49929 [::1]:9090 TIME_WAIT 0

          After running the same shutdown call again, server comes out of the serve call and it stops successfully.

          netstat -a -n -o | find "9090"
          TCP [::1]:49929 [::1]:9090 TIME_WAIT 0
          TCP [::1]:49930 [::1]:9090 TIME_WAIT 0

          Question is why do I need to call shutdown twice on windows, while same thing on linux works in the first shutdown itself.

          Following is the sequence of call stack:

          Server is waiting in following call where server is of type TThreadPoolServer:
          _server->serve();

          Client calls following:
          boost::shared_ptr<TSocket> socket(new TSocket("localhost", i_port));
          boost::shared_ptr<TTransport> transport(new TBufferedTransport(socket));
          boost::shared_ptr<TProtocol> protocol(new TBinaryProtocol(transport));
          #ifdef WIN32
          TWinsockSingleton::create(); ===using thrift patch 1031 and 1123
          #endif
          MyServerClient client(protocol);
          transport->open();
          client.shutdown();
          transport->close();

          Server gets a call in fb303’s shutdown call which I have overloaded to call server’s TThreadPoolServer::stop() function
          virtual void stop()

          { stop_ = true; serverTransport_->interrupt(); }

          Where above interrupt() call expands to following:

          void TServerSocket::interrupt() {
          if (intSock1_ >= 0) {
          int8_t byte = 0;
          if (-1 == send(intSock1_, reinterpret_cast<const buffer_unit_t *>(byte), sizeof(int8_t), 0))

          { GlobalOutput.perror("TServerSocket::interrupt() send() ", errno); ================this gets printed as “Thrift: Tue Aug 30 10:31:24 2011 TServerSocket::interrupt() send() errno = 0” }

          }
          }

          But only after the next call to shutdown(), it exists properly.

          Any clue on this behavior?

          Show
          Deepak Muley added a comment - Hello All, I am facing one interesting issue on windows while shutting down the windows server. I am using thrift patches 1031 and 1123 with 0.6.0 version of thrift. here is the sequence of events: After running server, I see that it is hosting the server as follows: netstat -a -n -o | find "9090" TCP 0.0.0.0:9090 0.0.0.0:0 LISTENING 2752 TCP [::] :9090 [::] :0 LISTENING 2752 After calling my server’s fb303 shutdown call from a client, Server prints following but does not come out of the loop: Thrift: Tue Aug 30 10:31:24 2011 TServerSocket::interrupt() send() errno = 0 netstat -a -n -o | find "9090" TCP 0.0.0.0:9090 0.0.0.0:0 LISTENING 2752 TCP [::] :9090 [::] :0 LISTENING 2752 TCP [::1] :49929 [::1] :9090 TIME_WAIT 0 After running the same shutdown call again, server comes out of the serve call and it stops successfully. netstat -a -n -o | find "9090" TCP [::1] :49929 [::1] :9090 TIME_WAIT 0 TCP [::1] :49930 [::1] :9090 TIME_WAIT 0 Question is why do I need to call shutdown twice on windows, while same thing on linux works in the first shutdown itself. Following is the sequence of call stack: Server is waiting in following call where server is of type TThreadPoolServer: _server->serve(); Client calls following: boost::shared_ptr<TSocket> socket(new TSocket("localhost", i_port)); boost::shared_ptr<TTransport> transport(new TBufferedTransport(socket)); boost::shared_ptr<TProtocol> protocol(new TBinaryProtocol(transport)); #ifdef WIN32 TWinsockSingleton::create(); ===using thrift patch 1031 and 1123 #endif MyServerClient client(protocol); transport->open(); client.shutdown(); transport->close(); Server gets a call in fb303’s shutdown call which I have overloaded to call server’s TThreadPoolServer::stop() function virtual void stop() { stop_ = true; serverTransport_->interrupt(); } Where above interrupt() call expands to following: void TServerSocket::interrupt() { if (intSock1_ >= 0) { int8_t byte = 0; if (-1 == send(intSock1_, reinterpret_cast<const buffer_unit_t *>(byte), sizeof(int8_t), 0)) { GlobalOutput.perror("TServerSocket::interrupt() send() ", errno); ================this gets printed as “Thrift: Tue Aug 30 10:31:24 2011 TServerSocket::interrupt() send() errno = 0” } } } But only after the next call to shutdown(), it exists properly. Any clue on this behavior?
          Hide
          Deepak Muley added a comment -

          Please ignore the x64 and x86 related issue. To rephrase the real issue, please refer to the following link. it explains the problem and some vague answer

          http://stackoverflow.com/questions/5859585/thrift-c-trouble-compiling-provided-tutorial-cannot-instantiate-abstract-clas

          I am facing the same error and it goes away if I make the changes in my processor class by adding above mentioned process function.

          Is this the only way?

          Show
          Deepak Muley added a comment - Please ignore the x64 and x86 related issue. To rephrase the real issue, please refer to the following link. it explains the problem and some vague answer http://stackoverflow.com/questions/5859585/thrift-c-trouble-compiling-provided-tutorial-cannot-instantiate-abstract-clas I am facing the same error and it goes away if I make the changes in my processor class by adding above mentioned process function. Is this the only way?
          Hide
          Deepak Muley added a comment -

          Has anybody faced following issue while using the windows port:

          When I compile the thrift file in x64 config, server using this file compile properly but when in x86 config, I have to explicitly add following code in autogenerated code to be able to make it compilable

          class MyServerProcessor : virtual public ::apache::thrift::TProcessor, public facebook::fb303::FacebookServiceProcessor {

          ...
          bool process(boost::shared_ptr<::apache::thrift::protocol::TProtocol> in,
          boost::shared_ptr<::apache::thrift::protocol::TProtocol> out,
          void* connectionContext)

          { return process(in,out); }

          ...

          else I get following error

          error C2259: 'MyServerProcessor' : cannot instantiate abstract class

          when i call as follows:

          boost::shared_ptr<TProcessor> processor(new MyServerProcessor(handler));

          Why does it happen only for x86 and not for x64? and how to fix it at the root else this is a manual steps for me all the time. Tried to compile the same with 0.6.1 windows thrift compiler as well but same behavior.

          Show
          Deepak Muley added a comment - Has anybody faced following issue while using the windows port: When I compile the thrift file in x64 config, server using this file compile properly but when in x86 config, I have to explicitly add following code in autogenerated code to be able to make it compilable class MyServerProcessor : virtual public ::apache::thrift::TProcessor, public facebook::fb303::FacebookServiceProcessor { ... bool process(boost::shared_ptr<::apache::thrift::protocol::TProtocol> in, boost::shared_ptr<::apache::thrift::protocol::TProtocol> out, void* connectionContext) { return process(in,out); } ... else I get following error error C2259: 'MyServerProcessor' : cannot instantiate abstract class when i call as follows: boost::shared_ptr<TProcessor> processor(new MyServerProcessor(handler)); Why does it happen only for x86 and not for x64? and how to fix it at the root else this is a manual steps for me all the time. Tried to compile the same with 0.6.1 windows thrift compiler as well but same behavior.
          Hide
          alexandre parenteau added a comment -

          I have created a fork of latest thrift 0.6.1 on github, which comprises part of this patch, and also uses THRIFT-923 (non-blocking server with libevent). If interested, please refer to https://github.com/aubonbeurre/thrift/blob/alex-0.6.1/README.non.blocking.Windows.

          Show
          alexandre parenteau added a comment - I have created a fork of latest thrift 0.6.1 on github, which comprises part of this patch, and also uses THRIFT-923 (non-blocking server with libevent). If interested, please refer to https://github.com/aubonbeurre/thrift/blob/alex-0.6.1/README.non.blocking.Windows .
          Hide
          Dragan Okiljevic added a comment -

          @Patrick Larser
          The patch does not support nonblocking server. You can take a look at changes made to other server implementations in order to get them work on WIN32, as it solves most of the problems like the one you reported (Cannot open include file 'unistd.h'), generally, you should just remove that include and add "#include <Config.h>" instead of it.
          I also think that nonblocking server depend on libevent library, so you would need to include it too.

          Show
          Dragan Okiljevic added a comment - @Patrick Larser The patch does not support nonblocking server. You can take a look at changes made to other server implementations in order to get them work on WIN32, as it solves most of the problems like the one you reported (Cannot open include file 'unistd.h'), generally, you should just remove that include and add "#include <Config.h>" instead of it. I also think that nonblocking server depend on libevent library, so you would need to include it too.
          Hide
          Patrick added a comment -

          I tried using TNonblockingServer, following the instructions at: http://wiki.apache.org/thrift/ThriftUsageC%2B%2B.

          Unfortunately, I am getting an error in server/TNonblockingServer.h:
          libthrift\server\tnonblockingserver.h(33): fatal error C1083: Cannot open include file: 'unistd.h': No such file or directory

          It looks like there's a dependance on a unix library. Has this been patched or is it a to-do for the windows conversion?

          Show
          Patrick added a comment - I tried using TNonblockingServer, following the instructions at: http://wiki.apache.org/thrift/ThriftUsageC%2B%2B . Unfortunately, I am getting an error in server/TNonblockingServer.h: libthrift\server\tnonblockingserver.h(33): fatal error C1083: Cannot open include file: 'unistd.h': No such file or directory It looks like there's a dependance on a unix library. Has this been patched or is it a to-do for the windows conversion?
          Hide
          Basudev Chaudhuri added a comment -

          Dragan and James,

          Thank you both for your great work. I really want to use thrift more and windows c++ support for the runtime has been a serious issue for me. Everything compiled great with Visual Studio 10.

          I was wondering if either of you know whether your changes, with some modifications, can be applied to the MinGW compile. I use the QtSDK 1.1, and the MinGW that comes with it. So there is no autoconf in the system or the setup to run bootstrap.sh.

          I did try to understand what it would take, and as a first test tried to just compile the same source as that for VS (with the patches in 1123).
          I defined _WIN32 for the build. Unfortunately I'm running into issues with the tr1 namespace.

          In file included from ..\..\src\concurrency\ThreadManager.cpp:20:
          ..\..\src\concurrency\/ThreadManager.h:61: error: 'std::tr1' has not been declared
          ..\..\src\concurrency\/ThreadManager.h:61: error: ISO C++ forbids declaration of 'function' with no type
          ..\..\src\concurrency\/ThreadManager.h:61: error: typedef name may not be a nested-name-specifier
          ..\..\src\concurrency\/ThreadManager.h:61: error: expected ';' before '<' token
          ..\..\src\concurrency\/ThreadManager.h:182: error: 'ExpireCallback' has not been declared
          ...

          Note that defining either _WIN32, or MINGW or both, all result in the same error.

          Sorry if this is the wrong place to bring this up, but in based on my experience so far (albeit limited) the plain non-nix MinGW setup and the VS setup should be pretty similar. Anything to push me in the right direction would be greatly appreciated.

          Thanks again.

          Show
          Basudev Chaudhuri added a comment - Dragan and James, Thank you both for your great work. I really want to use thrift more and windows c++ support for the runtime has been a serious issue for me. Everything compiled great with Visual Studio 10. I was wondering if either of you know whether your changes, with some modifications, can be applied to the MinGW compile. I use the QtSDK 1.1, and the MinGW that comes with it. So there is no autoconf in the system or the setup to run bootstrap.sh. I did try to understand what it would take, and as a first test tried to just compile the same source as that for VS (with the patches in 1123). I defined _WIN32 for the build. Unfortunately I'm running into issues with the tr1 namespace. In file included from ..\..\src\concurrency\ThreadManager.cpp:20: ..\..\src\concurrency\/ThreadManager.h:61: error: 'std::tr1' has not been declared ..\..\src\concurrency\/ThreadManager.h:61: error: ISO C++ forbids declaration of 'function' with no type ..\..\src\concurrency\/ThreadManager.h:61: error: typedef name may not be a nested-name-specifier ..\..\src\concurrency\/ThreadManager.h:61: error: expected ';' before '<' token ..\..\src\concurrency\/ThreadManager.h:182: error: 'ExpireCallback' has not been declared ... Note that defining either _WIN32, or MINGW or both, all result in the same error. Sorry if this is the wrong place to bring this up, but in based on my experience so far (albeit limited) the plain non-nix MinGW setup and the VS setup should be pretty similar. Anything to push me in the right direction would be greatly appreciated. Thanks again.
          Hide
          Ken Smith added a comment -

          Thanks, Deepak. That worked great.

          Show
          Ken Smith added a comment - Thanks, Deepak. That worked great.
          Hide
          Deepak Muley added a comment -

          As per the readme file which is located in the build_windows directory, this patch has a dependancy on pthreads on WIN32 (its a open source project, u will find on googling) library and boost APIs.

          Readme file also mentions that you needs to create the THRIFT_PARTY environment variable and put corresponding libraries there. if you have them at some other place then you can change the respective paths in the project settings.

          Hope that help. I am able to compile this patch on windows successfully.

          Show
          Deepak Muley added a comment - As per the readme file which is located in the build_windows directory, this patch has a dependancy on pthreads on WIN32 (its a open source project, u will find on googling) library and boost APIs. Readme file also mentions that you needs to create the THRIFT_PARTY environment variable and put corresponding libraries there. if you have them at some other place then you can change the respective paths in the project settings. Hope that help. I am able to compile this patch on windows successfully.
          Hide
          Ken Smith added a comment -

          I patched thrift (SVN rev 1099965) with the two patches attached to this ticket and when I try to build it using Visual C++ 2010 Express, I get the following error.

          ------ Build started: Project: libthrift, Configuration: Debug Win32 ------
          TWinsockUtil.cpp
          c:\documents and settings\user\desktop\thrift-win32-patched\lib\cpp\src\config.h(25): fatal error C1083: Cannot open include file: 'pthread.h': No such file or directory
          TWinsockSingleton.cpp
          c:\documents and settings\user\desktop\thrift-win32-patched\lib\cpp\src\transport\twinsocksingleton.h(4): fatal error C1083: Cannot open include file: 'boost/noncopyable.hpp': No such file or directory
          TSocket.cpp
          c:\documents and settings\user\desktop\thrift-win32-patched\lib\cpp\src\config.h(25): fatal error C1083: Cannot open include file: 'pthread.h': No such file or directory
          TServerSocket.cpp
          c:\documents and settings\user\desktop\thrift-win32-patched\lib\cpp\src\config.h(25): fatal error C1083: Cannot open include file: 'pthread.h': No such file or directory
          TBufferTransports.cpp
          c:\documents and settings\user\desktop\thrift-win32-patched\lib\cpp\src\transport\tbuffertransports.h(24): fatal error C1083: Cannot open include file: 'boost/scoped_array.hpp': No such file or directory
          TThreadedServer.cpp
          c:\documents and settings\user\desktop\thrift-win32-patched\lib\cpp\src\config.h(25): fatal error C1083: Cannot open include file: 'pthread.h': No such file or directory
          TThreadPoolServer.cpp
          c:\documents and settings\user\desktop\thrift-win32-patched\lib\cpp\src\concurrency\threadmanager.h(23): fatal error C1083: Cannot open include file: 'boost/shared_ptr.hpp': No such file or directory
          TSimpleServer.cpp
          c:\documents and settings\user\desktop\thrift-win32-patched\lib\cpp\src\config.h(25): fatal error C1083: Cannot open include file: 'pthread.h': No such file or directory
          Util.cpp
          c:\documents and settings\user\desktop\thrift-win32-patched\lib\cpp\src\config.h(25): fatal error C1083: Cannot open include file: 'pthread.h': No such file or directory
          TimerManager.cpp
          c:\documents and settings\user\desktop\thrift-win32-patched\lib\cpp\src\config.h(25): fatal error C1083: Cannot open include file: 'pthread.h': No such file or directory
          ThreadManager.cpp
          c:\documents and settings\user\desktop\thrift-win32-patched\lib\cpp\src\concurrency\threadmanager.h(23): fatal error C1083: Cannot open include file: 'boost/shared_ptr.hpp': No such file or directory
          PosixThreadFactory.cpp
          c:\documents and settings\user\desktop\thrift-win32-patched\lib\cpp\src\concurrency\thread.h(23): fatal error C1083: Cannot open include file: 'boost/shared_ptr.hpp': No such file or directory
          Mutex.cpp
          c:\documents and settings\user\desktop\thrift-win32-patched\lib\cpp\src\concurrency\mutex.h(23): fatal error C1083: Cannot open include file: 'boost/shared_ptr.hpp': No such file or directory
          Monitor.cpp
          c:\documents and settings\user\desktop\thrift-win32-patched\lib\cpp\src\config.h(25): fatal error C1083: Cannot open include file: 'pthread.h': No such file or directory
          Thrift.cpp
          c:\documents and settings\user\desktop\thrift-win32-patched\lib\cpp\src\config.h(25): fatal error C1083: Cannot open include file: 'pthread.h': No such file or directory
          TApplicationException.cpp
          c:\documents and settings\user\desktop\thrift-win32-patched\lib\cpp\src\config.h(25): fatal error C1083: Cannot open include file: 'pthread.h': No such file or directory
          Generating Code...
          ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

          To try and fix it, I installed Windows Services for Unix 3.5 but that didn't help it find pthread.h. How do I fix this?

          Show
          Ken Smith added a comment - I patched thrift (SVN rev 1099965) with the two patches attached to this ticket and when I try to build it using Visual C++ 2010 Express, I get the following error. ------ Build started: Project: libthrift, Configuration: Debug Win32 ------ TWinsockUtil.cpp c:\documents and settings\user\desktop\thrift-win32-patched\lib\cpp\src\config.h(25): fatal error C1083: Cannot open include file: 'pthread.h': No such file or directory TWinsockSingleton.cpp c:\documents and settings\user\desktop\thrift-win32-patched\lib\cpp\src\transport\twinsocksingleton.h(4): fatal error C1083: Cannot open include file: 'boost/noncopyable.hpp': No such file or directory TSocket.cpp c:\documents and settings\user\desktop\thrift-win32-patched\lib\cpp\src\config.h(25): fatal error C1083: Cannot open include file: 'pthread.h': No such file or directory TServerSocket.cpp c:\documents and settings\user\desktop\thrift-win32-patched\lib\cpp\src\config.h(25): fatal error C1083: Cannot open include file: 'pthread.h': No such file or directory TBufferTransports.cpp c:\documents and settings\user\desktop\thrift-win32-patched\lib\cpp\src\transport\tbuffertransports.h(24): fatal error C1083: Cannot open include file: 'boost/scoped_array.hpp': No such file or directory TThreadedServer.cpp c:\documents and settings\user\desktop\thrift-win32-patched\lib\cpp\src\config.h(25): fatal error C1083: Cannot open include file: 'pthread.h': No such file or directory TThreadPoolServer.cpp c:\documents and settings\user\desktop\thrift-win32-patched\lib\cpp\src\concurrency\threadmanager.h(23): fatal error C1083: Cannot open include file: 'boost/shared_ptr.hpp': No such file or directory TSimpleServer.cpp c:\documents and settings\user\desktop\thrift-win32-patched\lib\cpp\src\config.h(25): fatal error C1083: Cannot open include file: 'pthread.h': No such file or directory Util.cpp c:\documents and settings\user\desktop\thrift-win32-patched\lib\cpp\src\config.h(25): fatal error C1083: Cannot open include file: 'pthread.h': No such file or directory TimerManager.cpp c:\documents and settings\user\desktop\thrift-win32-patched\lib\cpp\src\config.h(25): fatal error C1083: Cannot open include file: 'pthread.h': No such file or directory ThreadManager.cpp c:\documents and settings\user\desktop\thrift-win32-patched\lib\cpp\src\concurrency\threadmanager.h(23): fatal error C1083: Cannot open include file: 'boost/shared_ptr.hpp': No such file or directory PosixThreadFactory.cpp c:\documents and settings\user\desktop\thrift-win32-patched\lib\cpp\src\concurrency\thread.h(23): fatal error C1083: Cannot open include file: 'boost/shared_ptr.hpp': No such file or directory Mutex.cpp c:\documents and settings\user\desktop\thrift-win32-patched\lib\cpp\src\concurrency\mutex.h(23): fatal error C1083: Cannot open include file: 'boost/shared_ptr.hpp': No such file or directory Monitor.cpp c:\documents and settings\user\desktop\thrift-win32-patched\lib\cpp\src\config.h(25): fatal error C1083: Cannot open include file: 'pthread.h': No such file or directory Thrift.cpp c:\documents and settings\user\desktop\thrift-win32-patched\lib\cpp\src\config.h(25): fatal error C1083: Cannot open include file: 'pthread.h': No such file or directory TApplicationException.cpp c:\documents and settings\user\desktop\thrift-win32-patched\lib\cpp\src\config.h(25): fatal error C1083: Cannot open include file: 'pthread.h': No such file or directory Generating Code... ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== To try and fix it, I installed Windows Services for Unix 3.5 but that didn't help it find pthread.h. How do I fix this?
          Hide
          Dragan Okiljevic added a comment -

          @Patrick Larser
          Thank you, I'm glad that you find it useful.

          As for the error, it seems like you didn't implement all handlers for operations defined for calculator service (in it's .thrift definition). These operations should be implemented in CalculatorProcessor class. When you generate source from .thrift file, you should find *_server.skeleton.cpp in gen-cpp. It contains main() that starts thrift server instance, and it has CalculatorProcessor with dummy implementation of all service operations.

          If you use this dummy CalculatorProcessor from *_server.skeleton.cpp you should be able to compile the code. The only other thing I can think of (if the first one don't help) is checking if the version of thrift compiler and thirftlib are the same, or at least compatible. But for CPP as far as I know every version of a compiler since 0.5 generates compatible sorce.

          Show
          Dragan Okiljevic added a comment - @Patrick Larser Thank you, I'm glad that you find it useful. As for the error, it seems like you didn't implement all handlers for operations defined for calculator service (in it's .thrift definition). These operations should be implemented in CalculatorProcessor class. When you generate source from .thrift file, you should find *_server.skeleton.cpp in gen-cpp. It contains main() that starts thrift server instance, and it has CalculatorProcessor with dummy implementation of all service operations. If you use this dummy CalculatorProcessor from *_server.skeleton.cpp you should be able to compile the code. The only other thing I can think of (if the first one don't help) is checking if the version of thrift compiler and thirftlib are the same, or at least compatible. But for CPP as far as I know every version of a compiler since 0.5 generates compatible sorce.
          Hide
          Patrick added a comment - - edited

          Thank you so much for porting this over. I was able to build libthrift.lib with minimal effort!
          I am having trouble compiling the tutorial code as defined in the patch's README. I'm able to generate Tutorial.thrift. But when I go to compile, I get:

          error C2259: 'tutorial::CalculatorProcessor' : cannot instantiate abstract class due to the following members: 'bool apache::thrift::TProcessor::process(boost::shared_ptr<T>,boost::shared_ptr<T>,void *)' : is abstract

          This occurs on the line:

          "shared_ptr<TProcessor> processor(new CalculatorProcessor(handler));"

          This is my first attempt in compiling Thrift code, any ideas why this occurs?

          Show
          Patrick added a comment - - edited Thank you so much for porting this over. I was able to build libthrift.lib with minimal effort! I am having trouble compiling the tutorial code as defined in the patch's README. I'm able to generate Tutorial.thrift. But when I go to compile, I get: error C2259: 'tutorial::CalculatorProcessor' : cannot instantiate abstract class due to the following members: 'bool apache::thrift::TProcessor::process(boost::shared_ptr<T>,boost::shared_ptr<T>,void *)' : is abstract This occurs on the line: "shared_ptr<TProcessor> processor(new CalculatorProcessor(handler));" This is my first attempt in compiling Thrift code, any ideas why this occurs?
          Hide
          Dragan Okiljevic added a comment - - edited

          Patch to fix byte order (endianness) on WIN32 C++ platform: "additional_thrift_cpp_visual_studio_2008_and_2010_endians_patch".

          Make sure to apply it after the main patch: "thrift_msvc_client_and_server.patch".

          Show
          Dragan Okiljevic added a comment - - edited Patch to fix byte order (endianness) on WIN32 C++ platform: "additional_thrift_cpp_visual_studio_2008_and_2010_endians_patch". Make sure to apply it after the main patch: "thrift_msvc_client_and_server.patch".
          Hide
          Dragan Okiljevic added a comment - - edited

          To use this patch for client&server C++ support in Visual Studion 2008 and 2010 environment (while waiting for it's improved version from issue THRIFT-1031 which is still under development and currently supports client side only) you need to make two more smaller changes, and your Win C++ Thrift powered project will work like a charm.

          These interventions are needed for THRIFT-1123 and possibly THRIFT-1031

          1. C++ code generated by Thrift compiler have compile errors if you define enums (some ambigious STL iterator as interpreted in Visual Studio) in .thrift file. The solution is easy and published as THRIFT-1139.

          2. When communicating between WIN32 client and servers on one side and other implementation such as Java on the other side, double values are not correctly interpreted as current C++ Thrift implementation don't recognise WIN32 environmant and decides to use wrong byte order (endianness). This does not affect int, string, complex and collection types, but affects double. The solution is easy and I'm providing it both inline and as a patch. It has been tested on Windows and transmited MBytes of collections/comples types/ints/doubles etc. between Java and C++.
          Here is the solution, provided both inline and as "additional_thrift_cpp_visual_studio_2008_and_2010_endians_patch(concerning_ticket_1123_and_possibly_1031_patches).patch". To use this patch, just make sure that the main, "thrift_msvc_client_and_server.patch", is already applied.

          TProtocol.h
          
          //around line 97 of TProtocol.h:
          
          //#if __BYTE_ORDER == __BIG_ENDIAN
          #if __BYTE_ORDER == __BIG_ENDIAN && !defined(WIN32)
          
          //around line 118 of TProtocol.h:
          
          //#elif __BYTE_ORDER == __LITTLE_ENDIAN
          #elif __BYTE_ORDER == __LITTLE_ENDIAN || !defined(WIN32)
          
          
          Show
          Dragan Okiljevic added a comment - - edited To use this patch for client&server C++ support in Visual Studion 2008 and 2010 environment (while waiting for it's improved version from issue THRIFT-1031 which is still under development and currently supports client side only) you need to make two more smaller changes, and your Win C++ Thrift powered project will work like a charm. These interventions are needed for THRIFT-1123 and possibly THRIFT-1031 1. C++ code generated by Thrift compiler have compile errors if you define enums (some ambigious STL iterator as interpreted in Visual Studio) in .thrift file. The solution is easy and published as THRIFT-1139 . 2. When communicating between WIN32 client and servers on one side and other implementation such as Java on the other side, double values are not correctly interpreted as current C++ Thrift implementation don't recognise WIN32 environmant and decides to use wrong byte order (endianness). This does not affect int, string, complex and collection types, but affects double. The solution is easy and I'm providing it both inline and as a patch. It has been tested on Windows and transmited MBytes of collections/comples types/ints/doubles etc. between Java and C++. Here is the solution, provided both inline and as "additional_thrift_cpp_visual_studio_2008_and_2010_endians_patch(concerning_ticket_1123_and_possibly_1031_patches).patch". To use this patch, just make sure that the main, "thrift_msvc_client_and_server.patch", is already applied. TProtocol.h //around line 97 of TProtocol.h: //# if __BYTE_ORDER == __BIG_ENDIAN # if __BYTE_ORDER == __BIG_ENDIAN && !defined(WIN32) //around line 118 of TProtocol.h: //#elif __BYTE_ORDER == __LITTLE_ENDIAN #elif __BYTE_ORDER == __LITTLE_ENDIAN || !defined(WIN32)
          Hide
          Dragan Okiljevic added a comment - - edited

          Christian and Roger, thank you for your feedback. The comments, advices and propositions you gave will be of big help for further development.

          Since James just published a new version of his patch at THRIFT-1031 and also answered on some of the questions concerning this issue, I posted a more detailed comment there.

          Show
          Dragan Okiljevic added a comment - - edited Christian and Roger, thank you for your feedback. The comments, advices and propositions you gave will be of big help for further development. Since James just published a new version of his patch at THRIFT-1031 and also answered on some of the questions concerning this issue, I posted a more detailed comment there.
          Hide
          James Dickson added a comment -

          Please see THRIFT-1031.

          Show
          James Dickson added a comment - Please see THRIFT-1031 .
          Hide
          Roger Meier added a comment -

          Good work James & Dragan!
          I agree with Christian's comments, here are my inputs and proposals:

          a) What about a new file lib/cpp/src/os/os.h which contains all operating specific stuff?
          Via os.h we can pull in some platform specific headers, e.g.

          #ifdef _WIN32
            #include windows.h // or windows_config.h
          #else
            // do we need a unix.h ? probably the parts from your Config.h
          #endif
          

          b) Another thing is transport/gettimeofday.cpp/.h
          What about placing that at lib/cpp/src/os/windows/ so that people recognize its intend clearly

          c) Config.h CLOSE_SOCKET, BLOCKING ... Are these defines really required?

          Show
          Roger Meier added a comment - Good work James & Dragan! I agree with Christian's comments, here are my inputs and proposals: a) What about a new file lib/cpp/src/os/os.h which contains all operating specific stuff? Via os.h we can pull in some platform specific headers, e.g. #ifdef _WIN32 #include windows.h // or windows_config.h #else // do we need a unix.h ? probably the parts from your Config.h #endif b) Another thing is transport/gettimeofday.cpp/.h What about placing that at lib/cpp/src/os/windows/ so that people recognize its intend clearly c) Config.h CLOSE_SOCKET, BLOCKING ... Are these defines really required?
          Hide
          Christian Lavoie added a comment -

          Thanks for the patch – looks mostly ok. A few comments:

          1) Config.h is a bad name – I'd rather it was called win32_config.h or platform_specifics.h or something like that.

          In particular, on Mac OS X case-insensitive filesystems are common and I'd rather ./configure doesn't overwrite an existing file under any circumstances.

          2) I like how you've done BIND and FLAGS and the rest of those, but they probably should be defined in their own namespace. Long story short, using ALL CAPITAL NAMES isn't the prettiest way to identify those as platform specific.

          3) I really don't like that Config.h (whatever it ends up being called) includes that many headers on UNIX. Is there a way to structure this so that the final .cpp files include only the .h they need, not everything that's currently in Config.h (whatever it ends up being called)?

          The solution to #2 and #3 may be the same, though that's a non-trivial undertaking.

          I've got a few nitpicks here and there, but they're minor compared to what's above (e.g.: why did you put (std::min) in parentheses in TBufferTransports.cpp ? )

          Show
          Christian Lavoie added a comment - Thanks for the patch – looks mostly ok. A few comments: 1) Config.h is a bad name – I'd rather it was called win32_config.h or platform_specifics.h or something like that. In particular, on Mac OS X case-insensitive filesystems are common and I'd rather ./configure doesn't overwrite an existing file under any circumstances. 2) I like how you've done BIND and FLAGS and the rest of those, but they probably should be defined in their own namespace. Long story short, using ALL CAPITAL NAMES isn't the prettiest way to identify those as platform specific. 3) I really don't like that Config.h (whatever it ends up being called) includes that many headers on UNIX. Is there a way to structure this so that the final .cpp files include only the .h they need, not everything that's currently in Config.h (whatever it ends up being called)? The solution to #2 and #3 may be the same, though that's a non-trivial undertaking. I've got a few nitpicks here and there, but they're minor compared to what's above (e.g.: why did you put (std::min) in parentheses in TBufferTransports.cpp ? )
          Hide
          Dragan Okiljevic added a comment -

          P.S. My excuses if I made any error while submitting this issue (including the decision to separate it from the original issue THRIFT-1031).

          Show
          Dragan Okiljevic added a comment - P.S. My excuses if I made any error while submitting this issue (including the decision to separate it from the original issue THRIFT-1031 ).
          Hide
          Dragan Okiljevic added a comment -

          The development was done by extending solution offered in THRIFT-1031

          Show
          Dragan Okiljevic added a comment - The development was done by extending solution offered in THRIFT-1031
          Hide
          Dragan Okiljevic added a comment -

          Revision 1086435 from March, 28, 2011. was used for development and creation of patch, but it should be possible to apply it on current trunk version, if no changes were made to relevant files in trunc.

          Show
          Dragan Okiljevic added a comment - Revision 1086435 from March, 28, 2011. was used for development and creation of patch, but it should be possible to apply it on current trunk version, if no changes were made to relevant files in trunc.

            People

            • Assignee:
              Unassigned
              Reporter:
              Dragan Okiljevic
            • Votes:
              2 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development