[
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"
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?
> 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 made to patched files in trunk.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
