[
https://issues.apache.org/jira/browse/THRIFT-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13008759#comment-13008759
]
Will Pierce commented on THRIFT-1094:
-------------------------------------
I think I know what the problem is. I only tested using python2.7... My bad.
I'll have to be more thorough in future patches.
Using python2.4 for testing, and running just the TSimpleServer test, the
import for the TProcessPool line chokes, since the multiprocessing module isn't
available in python2.4.
I get this output (the top of the output is more helpful, as the server
process's error gets buried with a lot of junk from the client and test runner):
{noformat}
% python2.4 ./RunClientServer.py 2>&1 | head -20
Traceback (most recent call last):
File "./TestServer.py", line 33, in ?
from thrift.server import TServer, TNonblockingServer, THttpServer,
TProcessPoolServer
File
"../../lib/py/build/lib.linux-x86_64-2.7/thrift/server/TProcessPoolServer.py",
line 22, in ?
from multiprocessing import Process, Value, Condition, reduction
ImportError: No module named multiprocessing
testByte (__main__.AcceleratedBinaryTest) ... ERROR
testDouble (__main__.AcceleratedBinaryTest) ... ERROR
testEnum (__main__.AcceleratedBinaryTest) ... ERROR
testException (__main__.AcceleratedBinaryTest) ... ERROR
testI32 (__main__.AcceleratedBinaryTest) ... ERROR
testI64 (__main__.AcceleratedBinaryTest) ... ERROR
testList (__main__.AcceleratedBinaryTest) ... ERROR
testMap (__main__.AcceleratedBinaryTest) ... ERROR
testMapMap (__main__.AcceleratedBinaryTest) ... ERROR
testMulti (__main__.AcceleratedBinaryTest) ... ERROR
testNest (__main__.AcceleratedBinaryTest) ... ERROR
testOneway (__main__.AcceleratedBinaryTest) ... ERROR
testOnewayThenNormal (__main__.AcceleratedBinaryTest) ... ERROR
testSet (__main__.AcceleratedBinaryTest) ... ERROR
{noformat}
The root problem is that the TProcessPool server uses a module unavailable in
python2.4. But there's no reason that should break the tests. It should
generate a warning maybe, in the 'except' clause, and skip testing that type of
server.
I'll update the patch so that the RunClientServer doesn't do the
TProcessPoolServer testing if the multiprocessing module is unavailable, and
update the {{import TProcessPoolServer}} line in TestServer.py so it is done
dynamically, not unconditionally.
I'll upload a corrected patch shortly.
> bug in TCompactProto python readMessageEnd method and updated test cases
> ------------------------------------------------------------------------
>
> Key: THRIFT-1094
> URL: https://issues.apache.org/jira/browse/THRIFT-1094
> Project: Thrift
> Issue Type: Bug
> Components: Python - Library
> Affects Versions: 0.6
> Reporter: Will Pierce
> Assignee: Will Pierce
> Attachments: THRIFT-1094.python_compactproto_fix_and_tests.patch
>
>
> The python implementation of TCompactProtocol has a bug in readMessageEnd, an
> assert on its internal state being READ_VALUE when it's actually CLEAR. I am
> including a patch that is 2 lines of library code change to
> TCompactProtocol.py, and a few dozen lines of ./test/py/ code changes.
> Changes in this patch:
> * fixed the readMessageEnd bug (2 lines)
> * added TCompactProto to the list of target protocols for the test suite
> * added a new --proto cmdline option to TestServer.py/TestClient.py to permit
> one of [accel, binary, compact]
> * changed RunTests.py so it has a nested loop, trying each protocol with each
> server type
> * added more client/server test methods for the ThriftTest service's:
> testNest(), testMap(), testSet(), testList(), testEnum(), testTypedef(),
> testMapMap(), testMulti()
> * fixed a bug in testOneWay() that was being passed a float instead of an int
> * added new TProcessPool class to list of servers and imports
> ** added extra code to shut down the individual process pool workers, to
> avoid leaving the server listen socket bound
> * added optional --port option to RunTests.py and TestServer.py so the port
> can be changed for both server & client from the RunTests.py cmdline
> * added optional argument to RunTests.py to run just a single server type,
> i.e. ./RunTests.py --port=9092 THttpServer
> * RunTests.py now prints out the exact cmdlines it executes for both server
> and client, to be more explicit
> * RunTests.py checks to make sure the server process didn't fail (via
> serverproc.poll() & serverproc.returncode test) which was a 'fixme' note in
> the code
> It takes a bit longer now for RunTests.py to execute, since it's testing 21
> combinations of 3 protocols and 7 server type (with 3.5 extra seconds of
> shutdown time for the TProcessPool server type). It's ~35 seconds now to run
> the whole suite, but gives more thorough code coverage for the tests.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
