Соответствующая строка в коде говорит
if (bytesRead < 0) {
throw new TTransportException(TTransportException.END_OF_FILE);
}
Вызывающий не смог прочитать len байтов из базового транспорта, что обычно означает, что удаленный конец завис(закрыл соединение):
/**
* Reads from the underlying input stream if not null.
*/
public int read(byte[] buf, int off, int len) throws TTransportException
{
if (inputStream_ == null) {
throw new TTransportException(TTransportException.NOT_OPEN, "Cannot read from null inputStream");
}
int bytesRead;
try {
bytesRead = inputStream_.read(buf, off, len);
} catch (IOException iox) {
throw new TTransportException(TTransportException.UNKNOWN, iox);
}
if (bytesRead < 0) {
throw new TTransportException(TTransportException.END_OF_FILE);
}
return bytesRead;
}
Для серверов, и у вас нет проблем, которые указывают на проблему, именно эта проблема заключается в том, как работает Thrift.
Для клиентов, какв вашем примере кажется, что сервер преждевременно закрыл соединение (клиент ожидает ответа TServiceClient.receiveBase()).
Наиболее вероятная причина - некоторая необработанная ошибка на стороне сервера.Еще одним возможным источником, который приходит на ум, может быть несоответствие стеков протокола / транспорта.