[
https://issues.apache.org/jira/browse/THRIFT-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739812#action_12739812
]
Joey A commented on THRIFT-171:
-------------------------------
I am seeing the same TransportException that Dave mentions above. The Ruby
client uses FramedTransport to communicate with a Java server. When more than
one Ruby thread communicates with the server, I'll *sometimes* receive the
error.
> Expected blocking from TSocket but didn't get it
> ------------------------------------------------
>
> Key: THRIFT-171
> URL: https://issues.apache.org/jira/browse/THRIFT-171
> Project: Thrift
> Issue Type: Bug
> Components: Library (Java), Library (Ruby)
> Affects Versions: 0.1
> Environment: CentOS 4.x
> Reporter: Dave Dupre
> Attachments: try.zip
>
>
> I have a Thrift server built in Ruby on Rails. It uses the TSimpleServer
> class since my server is using Rails to generate HTML (Rails view code
> expects to be single threaded). I have two clients: one in Java and one in
> Ruby. Here is what I see:
> Ruby client:
> # Usual init code straight from the tutorial here
> transport.open
> 1000.times { client.my_method }
> transport.close
> The Java client is basically the same. Unfortunately, I see two different
> behaviors when running multiple client instances. With a Ruby client,
> execute client A, and it starts processing normally. Execute client B while
> client A is still running, and it blocks at transport.open until client A
> completes. This is what I expected. However, if I do the same thing with
> Java clients, both clients proceed in parallel. Unfortunately, this gets the
> server very confused and into a really bad state. I'm using TSocket which
> should be doing blocking I/O, but that is not what I'm seeing happen.
> Is there some magic that I can do to make this work? Right now, I use
> configuration to ensure that only one Java client thread/process is allowed
> to talk to my Ruby server, but this is a total hack. Switching to
> TThreadedServer makes blocking go away, but I'm nervous about what that will
> mean to the Rails controller and view code. FYI, my server allows me to
> generate HTML views via Thrift. If it was a pure Ruby server, then I would
> not be concerned, but since so much is dependent on code that usually assumes
> to be single threaded, I'm concerned about introducing bugs.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
