MobileFirst 8.0 C# WorklightResourceRequest.Send() зависает, если устройство отключено

Я разрабатываю нативные клиентские LOB-приложения для Windows 10 для клиента.
Среда: Windows 10 Pro (на мобильных клиентах/планшетах и ​​в коробке разработчика), Visual Studio 2015 Professional с обновлением 3, все обновления и исправления установлены. Клиентское приложение использует самую последнюю версию «IBM MobileFirst Platform SDK для универсальных платформ Windows 8 и Windows 10» версии 8.0.2017012514. На отдельной машине в моей сети установлен MobileFirst Platform Server с адаптером Java.

Приложение работает очень хорошо, когда приложение подключено к сети и доступен сервер MobileFirst Platform 8.0.

Если клиент теряет подключение к сети (например, WLAN вне зоны досягаемости или МФУ-сервер отключен), то все запросы к серверу зависают на неопределенный срок. См. следующий пример кода C#:

    public async Task CallMethodMfp8()
    {
        Value = "Start MobileFirst Method Call " + DateTime.Now + "\n" + Value;
        StringBuilder uriBuilder = new StringBuilder().Append("/adapters")
            .Append("/MaximoAdapter")
            .Append("/admin")
            .Append("/heartbeat");
        WorklightResourceRequest rr = _client.ResourceRequest(new 
                   Uri(uriBuilder.ToString(), UriKind.Relative), "GET", "");
        rr.Timeout = 500;

        WorklightResponse resp = await rr.Send();

        if (!resp.Success)
        {
            Value = "NOT SUCCESSFULL " + resp.Message + "\n" + Value;
        }
        else
        {
            Value = "Request OK" + resp.ResponseText + "\n" + Value;
        }
        Value = "Method Call Finished " + DateTime.Now + "\n" + Value;
    }

Вызов rr.Send() не возвращается, если устройство находится в автономном режиме. Кроме того, параметр Timeout, по-видимому, не имеет никакого эффекта (согласно документам, это должно быть время ожидания в миллисекундах).

Такое поведение негативно влияет на удобство использования клиентского приложения.

Из чтения документов я ожидаю, что вызов вернется после настроенного тайм-аута и что поле resp.Success имеет значение false.

Я предполагаю, что вызов WorklightResourceRequest.Send() не должен зависать в автономном режиме и что это ошибка в библиотеке платформы MobileFirst.

Есть ли обходной путь для этого или я неправильно использую библиотеку?


person Wolfgang Fiedler    schedule 07.03.2017    source источник
comment
Обычно время ожидания по умолчанию для приложения Windows UWP составляет 90 секунд. Ваше приложение не отвечает в течение 90 секунд?   -  person Vittal Pai    schedule 08.03.2017
comment
Нет, приложение просто зависает навсегда (а у меня уже несколько часов). Даже если сеть возвращает вызов, он не продолжается.   -  person Wolfgang Fiedler    schedule 08.03.2017
comment
Мы можем воссоздать эту проблему. Эта проблема будет исправлена ​​в нашем следующем выпуске. Спасибо ..   -  person Vittal Pai    schedule 10.03.2017
comment
У вас есть предположения, когда будет готов следующий релиз? И я знаю, что мне не нужно вам об этом говорить, но существует множество различных причин, по которым клиент может быть отключен или почему сервер MobileFirst не может быть подключен. Я уверен, что мой клиент найдет их и протестирует их все...   -  person Wolfgang Fiedler    schedule 10.03.2017
comment
Помните, что вы всегда можете открыть PMR, чтобы получить исправление, пока iFix не будет готов к публикации.   -  person Idan Adar    schedule 10.03.2017
comment
Согласно ответу ниже, проблема была исправлена ​​2 недели назад. Когда я создал этот вопрос в stackoverflow, был создан PMR, также был создан APAR (PI78757). Я еще не получил исправления. Что еще я могу сделать? Мне нужно исправление, чтобы клиент мог продолжить тестирование...   -  person Wolfgang Fiedler    schedule 30.03.2017
comment
@WolfgangFiedler Вы можете запросить тестовое исправление через PMR, если оно вам нужно срочно, поскольку выпуск SDK занимает пару недель.   -  person Vittal Pai    schedule 04.04.2017


Ответы (1)


Проблема устранена, исправление будет опубликовано в следующем IFix.

person Shubha S    schedule 16.03.2017