thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Dodd <andrewdod...@gmail.com>
Subject Asynchronous RPC
Date Mon, 21 Jul 2014 05:18:27 GMT
Morning,

Over the last few days I've been experimenting with the code provided by
this article:
http://joelpm.com/2009/04/03/thrift-bidirectional-async-rpc.html . However,
that code doesn't exactly fit my needs. I checked out the source from
GitHub and did the following things:

1. Updated it to work with Thrift 0.9.1 - everything is OK here.
2. Changed the Service to use a different callback method (it does mean
several no-op implementations, but that is fine).
3. Changed the MessageDistributor to be instantiated once per client. This
means that rather than sending one response to each client, it is only sent
to the client which sent the request.

Up to this point everything works fine. However, I don't really want one
thread per client as it's potentially wasteful. So rather than do that, I
made the MessageDistributor submit a runnable into a shared Executor
Service. At this point, problems start to occur. When the client receives
it the first response, I get this message:

Exception in thread "Thread-2" java.lang.StringIndexOutOfBoundsException:
String index out of range: -2147418111
    at java.lang.String.checkBounds(String.java:371)
    at java.lang.String.<init>(String.java:415)
    at
org.apache.thrift.protocol.TBinaryProtocol.readString(TBinaryProtocol.java:326)
    at
org.apache.thrift.protocol.TBinaryProtocol.readMessageBegin(TBinaryProtocol.java:197)
    at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:27)
    at
com.joelpm.bidiMessages.client.MessageReceiver.run(MessageReceiver.java:31)
    at java.lang.Thread.run(Thread.java:745)

My thought on this is that the one-way message isn't actually completely
one-way; that we do send some sort of acknowledgement packet, and this is
causing a mess on the receiving end. I also notice that if I put a
breakpoint inside my call-back to the client (inside the server's code) and
let it run a while after, that I don't get an error and the message does
get received on the client, further strengthening my suspicions.

Can anyone confirm that this could be the issue?

Thanks,
Andrew

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message