[jira] [Commented] (THRIFT-976) c_glib tutorial

[jing hong (JIRA)]

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

jing hong commented on THRIFT-976:
--

Any progress on this?

> c_glib tutorial
> ---
>
> Key: THRIFT-976
> URL: https://issues.apache.org/jira/browse/THRIFT-976
> Project: Thrift
>  Issue Type: Improvement
>  Components: C glib - Compiler, C glib - Library, Tutorial
>Reporter: Roger Meier
>Assignee: Michael Lum
>Priority: Minor
>
> It would be great to have a tutorial for the brand new c_glib library.

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

[jira] [Created] (THRIFT-1313) c_glib compact support

[jing hong (JIRA)]

c_glib compact support
--

 Key: THRIFT-1313
 URL: https://issues.apache.org/jira/browse/THRIFT-1313
 Project: Thrift
  Issue Type: Improvement
  Components: C glib - Library
Affects Versions: 0.7
Reporter: jing hong


c_glib does not support compact protocol, any plans for that?

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

[jira] [Updated] (THRIFT-1312) Add MutexableThreadPoolServer and ProcessPoolServer

[Scott Gonyea (JIRA)]

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

Scott Gonyea updated THRIFT-1312:
-

Attachment: thrift-1312.patch

Removes ProcessPoolServer

> Add MutexableThreadPoolServer and ProcessPoolServer
> ---
>
> Key: THRIFT-1312
> URL: https://issues.apache.org/jira/browse/THRIFT-1312
> Project: Thrift
>  Issue Type: New Feature
>  Components: Ruby - Library
>Affects Versions: 0.7
>Reporter: Scott Gonyea
> Fix For: 0.8
>
> Attachments: thrift-1312.patch, thrift-1312.patch
>
>
> Hi, this feature request adds the verbosely-named "MutexableThreadPoolServer" 
> and "ProcessPoolServer" to the Thrift Ruby Library.
> The MutexableThreadPoolServer (MTPServer) contains a thorough set of tests, 
> as well as an example file that demonstrates its use.
> Below is a lengthy description of how we make use of the MTPServer.  But 
> before getting into that, you can find the code here, or in the included 
> patch.
> https://github.com/sgonyea/thrift/tree/mtps/lib/rb
> This draws very heavily from the ThreadPoolServer, except that it introduces 
> the use of Mutexes as one way to stop the server from spawning threads.  
> Further, it offers a #stop_threads method, that will check the state of each 
> thread and release control once all threads have finished serving requests to 
> clients.
> Internally, this MTPServer is used in conjunction with HAProxy to shut down 
> and start up, cleanly, and to avoid all sorts of crazy race conditions that 
> often arise when serving over a raw socket.
> When the MTPServer is started, it will fill the ThreadPool with N threads.  
> Once done, it is ready to receive requests and will yield to a callback if 
> one is supplied.  In this callback, we call out to HAProxy and signal that we 
> are ready to begin accepting connections from API clients.
> The parent application can be setup to trap any signals, as we do, and to 
> then lock the mutex (to prevent new threads from pooling).  It then calls 
> @server.stop_threads.  It also spins off another thread that will hard shut 
> down the server if Threads continue past an arbitrary amount of time.
> The other benefit in using HAProxy is that it will close connections from 
> clients, if they are idle for some period of time.  This prevents another 
> common issue, where a client remains connected and causes our Thread to 
> block, until the sun explodes.

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

[jira] [Commented] (THRIFT-1312) Add MutexableThreadPoolServer and ProcessPoolServer

[Scott Gonyea (JIRA)]

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

Scott Gonyea commented on THRIFT-1312:
--

Patch is now attached.

> Add MutexableThreadPoolServer and ProcessPoolServer
> ---
>
> Key: THRIFT-1312
> URL: https://issues.apache.org/jira/browse/THRIFT-1312
> Project: Thrift
>  Issue Type: New Feature
>  Components: Ruby - Library
>Affects Versions: 0.7
>Reporter: Scott Gonyea
> Fix For: 0.8
>
> Attachments: thrift-1312.patch
>
>
> Hi, this feature request adds the verbosely-named "MutexableThreadPoolServer" 
> and "ProcessPoolServer" to the Thrift Ruby Library.
> The MutexableThreadPoolServer (MTPServer) contains a thorough set of tests, 
> as well as an example file that demonstrates its use.
> Below is a lengthy description of how we make use of the MTPServer.  But 
> before getting into that, you can find the code here, or in the included 
> patch.
> https://github.com/sgonyea/thrift/tree/mtps/lib/rb
> This draws very heavily from the ThreadPoolServer, except that it introduces 
> the use of Mutexes as one way to stop the server from spawning threads.  
> Further, it offers a #stop_threads method, that will check the state of each 
> thread and release control once all threads have finished serving requests to 
> clients.
> Internally, this MTPServer is used in conjunction with HAProxy to shut down 
> and start up, cleanly, and to avoid all sorts of crazy race conditions that 
> often arise when serving over a raw socket.
> When the MTPServer is started, it will fill the ThreadPool with N threads.  
> Once done, it is ready to receive requests and will yield to a callback if 
> one is supplied.  In this callback, we call out to HAProxy and signal that we 
> are ready to begin accepting connections from API clients.
> The parent application can be setup to trap any signals, as we do, and to 
> then lock the mutex (to prevent new threads from pooling).  It then calls 
> @server.stop_threads.  It also spins off another thread that will hard shut 
> down the server if Threads continue past an arbitrary amount of time.
> The other benefit in using HAProxy is that it will close connections from 
> clients, if they are idle for some period of time.  This prevents another 
> common issue, where a client remains connected and causes our Thread to 
> block, until the sun explodes.

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

[jira] [Updated] (THRIFT-1312) Add MutexableThreadPoolServer and ProcessPoolServer

[Scott Gonyea (JIRA)]

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

Scott Gonyea updated THRIFT-1312:
-

Attachment: thrift-1312.patch

> Add MutexableThreadPoolServer and ProcessPoolServer
> ---
>
> Key: THRIFT-1312
> URL: https://issues.apache.org/jira/browse/THRIFT-1312
> Project: Thrift
>  Issue Type: New Feature
>  Components: Ruby - Library
>Affects Versions: 0.7
>Reporter: Scott Gonyea
> Fix For: 0.8
>
> Attachments: thrift-1312.patch
>
>
> Hi, this feature request adds the verbosely-named "MutexableThreadPoolServer" 
> and "ProcessPoolServer" to the Thrift Ruby Library.
> The MutexableThreadPoolServer (MTPServer) contains a thorough set of tests, 
> as well as an example file that demonstrates its use.
> Below is a lengthy description of how we make use of the MTPServer.  But 
> before getting into that, you can find the code here, or in the included 
> patch.
> https://github.com/sgonyea/thrift/tree/mtps/lib/rb
> This draws very heavily from the ThreadPoolServer, except that it introduces 
> the use of Mutexes as one way to stop the server from spawning threads.  
> Further, it offers a #stop_threads method, that will check the state of each 
> thread and release control once all threads have finished serving requests to 
> clients.
> Internally, this MTPServer is used in conjunction with HAProxy to shut down 
> and start up, cleanly, and to avoid all sorts of crazy race conditions that 
> often arise when serving over a raw socket.
> When the MTPServer is started, it will fill the ThreadPool with N threads.  
> Once done, it is ready to receive requests and will yield to a callback if 
> one is supplied.  In this callback, we call out to HAProxy and signal that we 
> are ready to begin accepting connections from API clients.
> The parent application can be setup to trap any signals, as we do, and to 
> then lock the mutex (to prevent new threads from pooling).  It then calls 
> @server.stop_threads.  It also spins off another thread that will hard shut 
> down the server if Threads continue past an arbitrary amount of time.
> The other benefit in using HAProxy is that it will close connections from 
> clients, if they are idle for some period of time.  This prevents another 
> common issue, where a client remains connected and causes our Thread to 
> block, until the sun explodes.

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

[jira] [Updated] (THRIFT-1312) Add MutexableThreadPoolServer and ProcessPoolServer

[Bryan Duxbury (JIRA)]

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

Bryan Duxbury updated THRIFT-1312:
--

Fix Version/s: (was: 0.7)

> Add MutexableThreadPoolServer and ProcessPoolServer
> ---
>
> Key: THRIFT-1312
> URL: https://issues.apache.org/jira/browse/THRIFT-1312
> Project: Thrift
>  Issue Type: New Feature
>  Components: Ruby - Library
>Affects Versions: 0.7
>Reporter: Scott Gonyea
> Fix For: 0.8
>
>
> Hi, this feature request adds the verbosely-named "MutexableThreadPoolServer" 
> and "ProcessPoolServer" to the Thrift Ruby Library.
> The MutexableThreadPoolServer (MTPServer) contains a thorough set of tests, 
> as well as an example file that demonstrates its use.
> Below is a lengthy description of how we make use of the MTPServer.  But 
> before getting into that, you can find the code here, or in the included 
> patch.
> https://github.com/sgonyea/thrift/tree/mtps/lib/rb
> This draws very heavily from the ThreadPoolServer, except that it introduces 
> the use of Mutexes as one way to stop the server from spawning threads.  
> Further, it offers a #stop_threads method, that will check the state of each 
> thread and release control once all threads have finished serving requests to 
> clients.
> Internally, this MTPServer is used in conjunction with HAProxy to shut down 
> and start up, cleanly, and to avoid all sorts of crazy race conditions that 
> often arise when serving over a raw socket.
> When the MTPServer is started, it will fill the ThreadPool with N threads.  
> Once done, it is ready to receive requests and will yield to a callback if 
> one is supplied.  In this callback, we call out to HAProxy and signal that we 
> are ready to begin accepting connections from API clients.
> The parent application can be setup to trap any signals, as we do, and to 
> then lock the mutex (to prevent new threads from pooling).  It then calls 
> @server.stop_threads.  It also spins off another thread that will hard shut 
> down the server if Threads continue past an arbitrary amount of time.
> The other benefit in using HAProxy is that it will close connections from 
> clients, if they are idle for some period of time.  This prevents another 
> common issue, where a client remains connected and causes our Thread to 
> block, until the sun explodes.

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

[jira] [Created] (THRIFT-1312) Add MutexableThreadPoolServer and ProcessPoolServer

[Scott Gonyea (JIRA)]

Add MutexableThreadPoolServer and ProcessPoolServer
---

 Key: THRIFT-1312
 URL: https://issues.apache.org/jira/browse/THRIFT-1312
 Project: Thrift
  Issue Type: New Feature
  Components: Ruby - Library
Affects Versions: 0.7
Reporter: Scott Gonyea
 Fix For: 0.8, 0.7


Hi, this feature request adds the verbosely-named "MutexableThreadPoolServer" 
and "ProcessPoolServer" to the Thrift Ruby Library.

The MutexableThreadPoolServer (MTPServer) contains a thorough set of tests, as 
well as an example file that demonstrates its use.

Below is a lengthy description of how we make use of the MTPServer.  But before 
getting into that, you can find the code here, or in the included patch.

https://github.com/sgonyea/thrift/tree/mtps/lib/rb

This draws very heavily from the ThreadPoolServer, except that it introduces 
the use of Mutexes as one way to stop the server from spawning threads.  
Further, it offers a #stop_threads method, that will check the state of each 
thread and release control once all threads have finished serving requests to 
clients.

Internally, this MTPServer is used in conjunction with HAProxy to shut down and 
start up, cleanly, and to avoid all sorts of crazy race conditions that often 
arise when serving over a raw socket.

When the MTPServer is started, it will fill the ThreadPool with N threads.  
Once done, it is ready to receive requests and will yield to a callback if one 
is supplied.  In this callback, we call out to HAProxy and signal that we are 
ready to begin accepting connections from API clients.

The parent application can be setup to trap any signals, as we do, and to then 
lock the mutex (to prevent new threads from pooling).  It then calls 
@server.stop_threads.  It also spins off another thread that will hard shut 
down the server if Threads continue past an arbitrary amount of time.

The other benefit in using HAProxy is that it will close connections from 
clients, if they are idle for some period of time.  This prevents another 
common issue, where a client remains connected and causes our Thread to block, 
until the sun explodes.


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

AW: Jenkins build is back to normal : Thrift #244

[Roger Meier]

Thanks Jake Farrell!

> -Ursprüngliche Nachricht-
> Von: Apache Jenkins Server [mailto:jenk...@builds.apache.org]
> Gesendet: Dienstag, 30. August 2011 21:52
> An: ro...@apache.org; dev@thrift.apache.org
> Betreff: Jenkins build is back to normal : Thrift #244
> 
> See 
> 
> 
> 

[jira] [Commented] (THRIFT-1286) Modernize the Thrift Ruby Library Dev Environment

[Scott Gonyea (JIRA)]

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

Scott Gonyea commented on THRIFT-1286:
--

Awesome, thank you.

> Modernize the Thrift Ruby Library Dev Environment
> -
>
> Key: THRIFT-1286
> URL: https://issues.apache.org/jira/browse/THRIFT-1286
> Project: Thrift
>  Issue Type: Improvement
>  Components: Ruby - Library
>Affects Versions: 0.7, 0.8
>Reporter: Scott Gonyea
>Assignee: Jake Farrell
> Fix For: 0.8
>
> Attachments: thrift-1286.patch, thrift-1286.patch, thrift-1286.patch, 
> thrift-1286.patch, thrift-1286.patch
>
>
> This fixes the ruby libraries environment. This introduces Bundler for 
> managing the development environment, as well as in handling the Gem release 
> process. Echoe is no longer present.
> The end result is that the development environment is easier to setup and 
> easier to reproduce.  Thus, easier to contribute to.
> This structures the spec folder to better follow conventions RSpec.
> The RSpec, as used in the ruby library, was using a mix of RSpec 1 and RSpec 
> 2. This brings everything into the land of RSpec 2.  Some additional cleanup 
> could definitely be done, but this gets us out of the deprecation warnings 
> and other weird behavior-ings.
> To run this in CI, however that is done, you'll effectively want the shell 
> script (or whatever) to look like this:
> which bundle || gem install bundler
> bundle install
> bundle exec rake spec
> Patch should be pulled from:
> https://github.com/sgonyea/thrift/compare/apache:trunk...1fd22f135700c5d32244c63c164610f52b94619b
> or up to the commit:
> https://github.com/sgonyea/thrift/commit/1fd22f135700c5d32244c63c164610f52b94619b

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

[jira] [Commented] (THRIFT-1286) Modernize the Thrift Ruby Library Dev Environment

[Hudson (JIRA)]

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

Hudson commented on THRIFT-1286:


Integrated in Thrift #244 (See [https://builds.apache.org/job/Thrift/244/])
Thrift-1286: Modernize the Thrift Ruby Library Dev Environment
Client: Ruby
Patch: jfarrell

Updates to ruby build process with the following changes:
 - Removes dependency on echoe for spec generation
 - Adds gemfile for bulider and uses thrift.gemspec for dependency management.
 - Adds checks in configure for builder and only calls if available (make 
check-local on ci servers)
 - Adds checks in configure for Ruby and rake (bundler as well but this is 
optional for check-local and auto dependency management)
 - Still allows for rake to do its thing if all dependencies are in place
 - Removed Manifest and setup.rb
 - Adds a install task which will generate a gem and then install that gem to 
locally configured ruby path (no more prefix or destdir with this client)


> Modernize the Thrift Ruby Library Dev Environment
> -
>
> Key: THRIFT-1286
> URL: https://issues.apache.org/jira/browse/THRIFT-1286
> Project: Thrift
>  Issue Type: Improvement
>  Components: Ruby - Library
>Affects Versions: 0.7, 0.8
>Reporter: Scott Gonyea
>Assignee: Jake Farrell
> Fix For: 0.8
>
> Attachments: thrift-1286.patch, thrift-1286.patch, thrift-1286.patch, 
> thrift-1286.patch, thrift-1286.patch
>
>
> This fixes the ruby libraries environment. This introduces Bundler for 
> managing the development environment, as well as in handling the Gem release 
> process. Echoe is no longer present.
> The end result is that the development environment is easier to setup and 
> easier to reproduce.  Thus, easier to contribute to.
> This structures the spec folder to better follow conventions RSpec.
> The RSpec, as used in the ruby library, was using a mix of RSpec 1 and RSpec 
> 2. This brings everything into the land of RSpec 2.  Some additional cleanup 
> could definitely be done, but this gets us out of the deprecation warnings 
> and other weird behavior-ings.
> To run this in CI, however that is done, you'll effectively want the shell 
> script (or whatever) to look like this:
> which bundle || gem install bundler
> bundle install
> bundle exec rake spec
> Patch should be pulled from:
> https://github.com/sgonyea/thrift/compare/apache:trunk...1fd22f135700c5d32244c63c164610f52b94619b
> or up to the commit:
> https://github.com/sgonyea/thrift/commit/1fd22f135700c5d32244c63c164610f52b94619b

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

Jenkins build is back to normal : Thrift #244

[Apache Jenkins Server]

See 

[jira] [Closed] (THRIFT-1286) Modernize the Thrift Ruby Library Dev Environment

[Jake Farrell (JIRA)]

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

Jake Farrell closed THRIFT-1286.


   Resolution: Fixed
Fix Version/s: (was: 0.7)

Updated ruby build with latest patch and configure checks

> Modernize the Thrift Ruby Library Dev Environment
> -
>
> Key: THRIFT-1286
> URL: https://issues.apache.org/jira/browse/THRIFT-1286
> Project: Thrift
>  Issue Type: Improvement
>  Components: Ruby - Library
>Affects Versions: 0.7, 0.8
>Reporter: Scott Gonyea
>Assignee: Jake Farrell
> Fix For: 0.8
>
> Attachments: thrift-1286.patch, thrift-1286.patch, thrift-1286.patch, 
> thrift-1286.patch, thrift-1286.patch
>
>
> This fixes the ruby libraries environment. This introduces Bundler for 
> managing the development environment, as well as in handling the Gem release 
> process. Echoe is no longer present.
> The end result is that the development environment is easier to setup and 
> easier to reproduce.  Thus, easier to contribute to.
> This structures the spec folder to better follow conventions RSpec.
> The RSpec, as used in the ruby library, was using a mix of RSpec 1 and RSpec 
> 2. This brings everything into the land of RSpec 2.  Some additional cleanup 
> could definitely be done, but this gets us out of the deprecation warnings 
> and other weird behavior-ings.
> To run this in CI, however that is done, you'll effectively want the shell 
> script (or whatever) to look like this:
> which bundle || gem install bundler
> bundle install
> bundle exec rake spec
> Patch should be pulled from:
> https://github.com/sgonyea/thrift/compare/apache:trunk...1fd22f135700c5d32244c63c164610f52b94619b
> or up to the commit:
> https://github.com/sgonyea/thrift/commit/1fd22f135700c5d32244c63c164610f52b94619b

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

[jira] [Updated] (THRIFT-1286) Modernize the Thrift Ruby Library Dev Environment

[Jake Farrell (JIRA)]

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

Jake Farrell updated THRIFT-1286:
-

Attachment: thrift-1286.patch

Updated patch with the following features 

- Removes dependency on echoe for spec generation
- Adds gemfile for bulider and uses thrift.gemspec for dependency management.
- adds checks in configure for builder and only calls if available (make 
check-local on ci servers)
- Adds checks in configure for Ruby and rake (bundler as well but this is 
optional for check-local and auto dependency management)
- still allows for rake to do its thing if all dependencies are in place
- Removed Manifest and setup.rb
- Adds a install task which will generate a gem and then install that gem to 
locally configured ruby path (no more prefix or destdir with this client)

> Modernize the Thrift Ruby Library Dev Environment
> -
>
> Key: THRIFT-1286
> URL: https://issues.apache.org/jira/browse/THRIFT-1286
> Project: Thrift
>  Issue Type: Improvement
>  Components: Ruby - Library
>Affects Versions: 0.7, 0.8
>Reporter: Scott Gonyea
>Assignee: Jake Farrell
> Fix For: 0.7, 0.8
>
> Attachments: thrift-1286.patch, thrift-1286.patch, thrift-1286.patch, 
> thrift-1286.patch, thrift-1286.patch
>
>
> This fixes the ruby libraries environment. This introduces Bundler for 
> managing the development environment, as well as in handling the Gem release 
> process. Echoe is no longer present.
> The end result is that the development environment is easier to setup and 
> easier to reproduce.  Thus, easier to contribute to.
> This structures the spec folder to better follow conventions RSpec.
> The RSpec, as used in the ruby library, was using a mix of RSpec 1 and RSpec 
> 2. This brings everything into the land of RSpec 2.  Some additional cleanup 
> could definitely be done, but this gets us out of the deprecation warnings 
> and other weird behavior-ings.
> To run this in CI, however that is done, you'll effectively want the shell 
> script (or whatever) to look like this:
> which bundle || gem install bundler
> bundle install
> bundle exec rake spec
> Patch should be pulled from:
> https://github.com/sgonyea/thrift/compare/apache:trunk...1fd22f135700c5d32244c63c164610f52b94619b
> or up to the commit:
> https://github.com/sgonyea/thrift/commit/1fd22f135700c5d32244c63c164610f52b94619b

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

[jira] [Commented] (THRIFT-1123) Patch to compile Thrift server and client for vc++ 9.0 and 10.0

[Deepak Muley (JIRA)]

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

Deepak Muley commented on THRIFT-1123:
--

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"
  TCP0.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"
  TCP0.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 socket(new TSocket("localhost", 
i_port));
  boost::shared_ptr transport(new 
TBufferedTransport(socket));
  boost::shared_ptr 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(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?


> Patch to compile Thrift server and client for vc++ 9.0 and 10.0
> ---
>
> Key: THRIFT-1123
> URL: https://issues.apache.org/jira/browse/THRIFT-1123
> Project: Thrift
>  Issue Type: Improvement
>  Components: C++ - Library
> Environment: Windows XP 32bit, vc++ 9.0, 10.0
>Reporter: Dragan Okiljevic
>Priority: Trivial
> Fix For: 0.8
>
> Attachments: 
> additional_thrift_cpp_visual_studio_2008_and_2010_endians_patch(concerning_ticket_1123_and_possibly_1031_patches).patch,
>  thrift_msvc_client_and_server.patch
>
>
> 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 mad

[jira] [Created] (THRIFT-1311) Recent changes on Java library break Java JSON protocol

[Henrique Mendonca (JIRA)]

Recent changes on Java library break Java JSON protocol
---

 Key: THRIFT-1311
 URL: https://issues.apache.org/jira/browse/THRIFT-1311
 Project: Thrift
  Issue Type: Bug
  Components: Java - Library
Reporter: Henrique Mendonca


I see that some people have been working very hard on the Java library and 
that's really appreciated, however, some of the changes seem to have interfered 
with the java server JSON/HTTP implementation which is used to test the JS 
client. Please see below:

thrift/lib/js/test$ ant testserver 
[...]
 [java] New connection thread
 [java] Incoming content: [1,"testSet",1,0,{"1":{"set":["i32",3,1,2,3]}}]
 [java] Outgoing content: Error:Unexpected character:[
 [java] New connection thread
 [java] Incoming content: [1,"testList",1,0,{"1":{"lst":["i32",3,1,2,3]}}]
 [java] Outgoing content: Error:Unexpected character:[

ps.: I hope one day we can automatize these tests with node.js, or something 
like that, so we don't need to run this manually

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

[jira] [Updated] (THRIFT-1310) Generate PHP client code not check sequence ID in messages

[Fang Jian (JIRA)]

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

Fang Jian updated THRIFT-1310:
--

Attachment: t_php_generator.patch

patch for compiler/cpp/src/generate/t_php_generator.cc

> Generate PHP client code not check sequence ID in messages
> --
>
> Key: THRIFT-1310
> URL: https://issues.apache.org/jira/browse/THRIFT-1310
> Project: Thrift
>  Issue Type: Bug
>  Components: PHP - Compiler
>Affects Versions: 0.7
>Reporter: Fang Jian
> Attachments: t_php_generator.patch
>
>
> The PHP client code not check sequence ID in messages, when client connect 
> timeout, the return of results are out of sequence. I try to fix this by 
> throwing a exception when sequence ID not equal. Patch file is listed below.

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

[jira] [Updated] (THRIFT-1310) Generate PHP client code not check sequence ID in messages

[Fang Jian (JIRA)]

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

Fang Jian updated THRIFT-1310:
--

Labels:   (was: patch)

> Generate PHP client code not check sequence ID in messages
> --
>
> Key: THRIFT-1310
> URL: https://issues.apache.org/jira/browse/THRIFT-1310
> Project: Thrift
>  Issue Type: Bug
>  Components: PHP - Compiler
>Affects Versions: 0.7
>Reporter: Fang Jian
> Attachments: t_php_generator.patch
>
>
> The PHP client code not check sequence ID in messages, when client connect 
> timeout, the return of results are out of sequence. I try to fix this by 
> throwing a exception when sequence ID not equal. Patch file is listed below.

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

[jira] [Updated] (THRIFT-1310) Generate PHP client code not check sequence ID in messages

[Fang Jian (JIRA)]

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

Fang Jian updated THRIFT-1310:
--

Patch Info:   (was: [Patch Available])

> Generate PHP client code not check sequence ID in messages
> --
>
> Key: THRIFT-1310
> URL: https://issues.apache.org/jira/browse/THRIFT-1310
> Project: Thrift
>  Issue Type: Bug
>  Components: PHP - Compiler
>Affects Versions: 0.7
>Reporter: Fang Jian
> Attachments: t_php_generator.patch
>
>
> The PHP client code not check sequence ID in messages, when client connect 
> timeout, the return of results are out of sequence. I try to fix this by 
> throwing a exception when sequence ID not equal. Patch file is listed below.

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

[jira] [Created] (THRIFT-1310) Generate PHP client code not check sequence ID in messages

[Fang Jian (JIRA)]

Generate PHP client code not check sequence ID in messages
--

 Key: THRIFT-1310
 URL: https://issues.apache.org/jira/browse/THRIFT-1310
 Project: Thrift
  Issue Type: Bug
  Components: PHP - Compiler
Affects Versions: 0.7
Reporter: Fang Jian


The PHP client code not check sequence ID in messages, when client connect 
timeout, the return of results are out of sequence. I try to fix this by 
throwing a exception when sequence ID not equal. Patch file is listed below.

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