Uploaded image for project: 'Thrift'
  1. Thrift
  2. THRIFT-4858

Java TThreadPoolServer: confusing error message on closed socket

VotersWatch issueWatchersLinkCloneUpdate Comment AuthorReplace String in CommentUpdate Comment VisibilityDelete Comments


    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 0.12.0
    • Fix Version/s: 0.13.0
    • Component/s: Java - Library
    • Labels:
    • Environment:


      I've spotted an error in using java libthrift that I'd like to call to your attention. It is in version 0.12.0, but I see it in other versions. I will comment about the other versions at the end, please read - it may be very important to you.

      I create a TThreadPoolServer, and when my client calls a method, the server spawns off a worker thread and when it gets to this line (in TThreadPoolServer):

      if(stopped_ || !processor.process(inputProtocol, outputProtocol)) {


      It will call a TBaseProcessor's process method, which can only return either True or throw an Exception. In my case, it gets to the very bottom and calls the ProcessFunction fn properly:

      fn.process(msg.seqid, in, out, iface);

      Followed by returning true. However, since the TThreadPoolServer will not "break" out of the while(true) loop it is in, it will attempt to call the TBaseProcessor's process method again and this time around I get an exception when this line is called on TBaseProcessor's process method:

      TMessage msg = in.readMessageBegin();

      Exception is:

      17844 [pool-6-thread-5] ERROR org.apache.thrift.server.TThreadPoolServer - Thrift error occurred during processing of message.

      at org.apache.thrift.transport.TIOStreamTransport.read(TIOStreamTransport.java:132
      at org.apache.thrift.transport.TTransport.readAll(TTransport.java:86)
      at org.apache.thrift.transport.TFramedTransport.readFrame(TFramedTransport.java:132)
      at org.apache.thrift.transport.TFramedTransport.read(TFramedTransport.java:100)
      at org.apache.thrift.transport.TTransport.readAll(TTransport.java:86)
      at org.apache.thrift.protocol.TBinaryProtocol.readAll(TBinaryProtocol.java:425)
      at org.apache.thrift.protocol.TBinaryProtocol.readI32(TBinaryProtocol.java:321)
      at org.apache.thrift.protocol.TBinaryProtocol.readMessageBegin(TBinaryProtocol.java:225)
      at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:33)
      at org.apache.thrift.server.TThreadPoolServer$WorkerProcess.run(TThreadPoolServer.java:318)
      at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
      at java.lang.Thread.run(Thread.java:748)

      I surmise because my TProtocol in has already sent the bytes (I am using a TBinaryProtocol) to the process function, there is nothing left to read and thus we never make it to the next line:

      ProcessFunction fn = processMap.get(msg.name);

      For giggles, I decided to remove the ! from the logic, and sure enough it gets by but it appears to perhaps cause other problems when a client calls a method with zero parameters (e.g. "ping()").

      Other versions: So far as I can tell this exact same code set up is in java libthrift 0.9.0, 0.9.1, and However, my Java code works just fine in those. I only discovered this problem when I went to upgrade my code to Thrift 0.12.0. I honestly can't make sense of why that would be OK in those older versions but, I've been blissfully unaware of this problem until the upgrade. It is possible I need to now do something that I did not before. That is because before, I used TThreadPoolServer with 0.9.x as I want to do now in 0.12.x. I figured perhaps something else is happening in Thrift with my TThreadPoolServer. Finally, I did see the problem in 0.12.1 and did not test it, though it appears changed in the master branch - we tried it and it still has errors.


        Issue Links



            • Assignee:
              nsuke Nobuaki Sukegawa
              mczajkow Michael Czajkowski


              • Created:

                Time Tracking

                Original Estimate - Not Specified
                Not Specified
                Remaining Estimate - 0h
                Time Spent - 20m

                  Issue deployment