Возникли проблемы при чтении ответа http в поток ввода - PullRequest
2 голосов
/ 15 марта 2012

Я вызываю веб-сервис .Net из моего приложения Blackberry. После проблем с KSoap2 я решил сделать все вручную. Вот фрагмент кода:

byte [] postDataBytes = soapRequestEnvelope.getBytes();
byte [] dataRetrieved;

    try
    {
        HttpConnection connection = (HttpConnection)Connector.open(URL);

        connection.setRequestMethod(HttpConnection.POST);
        connection.setRequestProperty("soapaction", soapAction);
        connection.setRequestProperty("Content-Type", "text/xml; charset=utf-8");

        os = connection.openOutputStream();
        os.write(postDataBytes);

        int rc = connection.getResponseCode();

        if(rc == HttpConnection.HTTP_OK)
        {
            inputStream = connection.openInputStream();
            dataRetrieved = new byte[(int)connection.getLength()];
            int bytesRead = inputStream .read(dataRetrieved);

        }
        else
        {

            dataRetrieved = null;

        }


        String dataString = new String(dataRetrieved);

//HttpConnection = javax.microedition.io.HttpConnection

//inputStream = java.io.InputStream

Проблема, с которой я столкнулся, заключается в том, что XML, который я получаю от вызова веб-службы, обрывается.

Когда я печатаю количество принятых байтов на экране, иногда появляется 1170 (что на самом деле соответствует размеру ответа, который я ожидаю в данной конкретной ситуации).

Но в других случаях количество полученных байтов равно 702 ...... почему 702 ???

Я тестировал около десятка раз подряд и получил следующий результат:

1170, 702, 1170, 1170, 702, 1170, 1170, 702, 1170, 702, 1170, 702, 702, 702, 1170, 702

Но почему 702 ?? Когда это портит и не работает, почему это так последовательно ?? Хотя он всегда выделяет 1170 байт, но почему иногда он читает только 702 ??

Это очень странно.

РЕДАКТИРОВАТЬ: я попытался вывести inputStream.available () на экран, а также для сравнения, совершенно не соответствует. Он варьируется между 0, 702 и 1170. Иногда доступные байты равны 0 или 702, а считываемые байты - 1170. Я совершенно сбит с толку.

Любая помощь будет принята с благодарностью.

Спасибо

Ответы [ 2 ]

4 голосов
/ 15 марта 2012

После своего рода смутного комментария, я полагаю, я должен указать, что я имел в виду под "поместить это read в цикл".Как определено , read вернет количество прочитанных байтов, или -1, если достигнут конец файла.

При чтении из сокета вы можете вызывать read() до того, каквсе данные были возвращены вам с сервера.Практический эффект этого заключается в том, что вы звоните read() и получаете меньше данных, чем ожидаете.Это просто означает, что вам нужно вызывать его снова (и снова, и снова), пока вы не получите все данные.

Я бы предложил использовать простой буфер фиксированного размера и проходить по read(), пока вы не получите -1и что-то делать с каждым чанком (например, записывая его в файл). Это избавляет вас от необходимости хранить весь файл в памяти.Например:

byte buf[1024];
int len;

while((len = read(buf)) >= 0)
{
    /* do something with len bytes of buf */
}

Конечно, у вас может быть гарантия, что файл будет маленьким, и вы действительно хотите, чтобы все это было в памяти.В этом случае вы можете (как вы сделали выше) просто выделить буфер размером connection.getLength(), однако вам нужно будет вызвать 3-arg read(byte[], int, int) и сделать немного больше обслуживания:

int remain = (int) connection.getLength();
byte buf[remain];
int offset = 0, len;

while((len = read(buf, offset, remain)) >= 0)
{
    offset += len;
    remain -= len;
}
1 голос
/ 15 марта 2012

Сетевые сообщения разбиты на пакеты. Целое сообщение занимает 2 пакета в вашем случае. InputStream.read (byte []) читает столько байтов, сколько было получено. Чтобы прочитать сообщение целиком, необходимо выполнить цикл до тех пор, пока не будут прочитаны байты connection.getLength (), или пока InputStream.read () не вернет -1.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...