Тайм-аут для запроса сервера, сделанного с помощью "Volley", только на Android, а не на iOS

В одном из моих приложений я отправляю запрос на сервер с помощью volley, предоставляемого Google.

Проблема: объект ожидания и ошибки имеет значение null на onErrorResponse(VolleyError error)

Что я пробовал до сих пор:

1) Сначала я получил нулевой объект ошибки, поэтому решил его использовать с помощью кода ниже:

 @Override
 protected void deliverResponse(String response) {
    super.deliverResponse(response);
 }

 @Override
 public void deliverError(VolleyError error) {
     super.deliverError(error);
     DebugLog.e("deliverResponse", "getNetworkTimeMs : " + error.getNetworkTimeMs());
 }

До сих пор я обнаружил, что существует timeout, когда я получил объект ошибки null.

2) Теперь приложение предназначено для Android и iOS и web, но timeout происходит только для Android.

Журнал волейбола для запросов:

BasicNetwork.logSlowRequests: HTTP response for request

Отредактированное примечание:

Веб-службы, созданные на сервере, одинаковы для всех трех экземпляров (Android, Web и iOS).
timeout происходит, когда слишком много пользователей делают запросы на сервер.
Я установил время до 2 минут, хотя волейбол бросает таймаут за 30 секунд только иногда.
У меня есть много ответов на изменение сервера, но так как это невозможно, так что любое другое решение, пожалуйста.

Я также хотел бы добавить, что если я могу получить больше информации о том, когда таймаут может быть возможен в залпе?

Ссылки Я прошел через:

Оптимизация волейбола

httpclient-often-times-out-using-wifi-is-going-fine-with-3g

long_xmlhttprequest_ajax_requests_timeout_on_android

Отредактировано:

Я также установил политику повтора, как показано ниже:

request.setRetryPolicy(new DefaultRetryPolicy(DefaultRetryPolicy.DEFAULT_TIMEOUT_MS * 48,
                0, DefaultRetryPolicy.DEFAULT_BACKOFF_MULT));

А также я не хочу повторять, если время ожидания соединения.

Как я могу сделать эффективный вызов службы, который может решить проблему для timeout.

Любая помощь будет назначена.

Спасибо.

Ответ 1

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

Вы можете обновить производительность своего сервера.
Я пробовал сделать запрос веб-сервиса, используя HttpURLConnection, но все же получаю такую же проблему.

Итак, я думаю, что эта проблема не связана с волейболом, но вы получаете эту проблему, тогда я бы предложил увеличить производительность сервера с настройкой ниже RetryPolicy:

int x=2;// retry count
request.setRetryPolicy(new DefaultRetryPolicy(DefaultRetryPolicy.DEFAULT_TIMEOUT_MS * 48,
                    x, DefaultRetryPolicy.DEFAULT_BACKOFF_MULT));

Надеюсь, это поможет.

Предложения всегда приветствуются:)

Прокомментируйте ниже, если вы нашли более правильное решение.

Спасибо.

Ответ 2

IMHO, вы можете обратиться к следующему:

Внутри BasicNetwork.java вы найдете некоторую информацию, например:

...
private static int SLOW_REQUEST_THRESHOLD_MS = 3000;
...
    /**
     * Logs requests that took over SLOW_REQUEST_THRESHOLD_MS to complete.
     */
    private void logSlowRequests(long requestLifetime, Request<?> request,
            byte[] responseContents, StatusLine statusLine) {
        if (DEBUG || requestLifetime > SLOW_REQUEST_THRESHOLD_MS) {
            VolleyLog.d("HTTP response for request=<%s> [lifetime=%d], [size=%s], " +
                    "[rc=%d], [retryCount=%s]", request, requestLifetime,
                    responseContents != null ? responseContents.length : "null",
                    statusLine.getStatusCode(), request.getRetryPolicy().getCurrentRetryCount());
        }
    }
...

// if the request is slow, log it.
long requestLifetime = SystemClock.elapsedRealtime() - requestStart;
logSlowRequests(requestLifetime, request, responseContents, statusLine);
...

Итак, если ваш проект использует Google volley в качестве модуля (а не JAR файл), вы можете обновить BasicNetwork.java, увеличив SLOW_REQUEST_THRESHOLD_MS значение, возможно, 10000 (мс) или больше, например.

Другая опция, согласно @neuron, ответит на следующий вопрос:

Как оптимизировать сетевой прием в андроид-волейбол? (Volley Google IO 2013)

Я думаю, вы можете попробовать увеличить значение NETWORK_THREAD_POOL_SIZE, используя следующий конструктор в своем приложении:

public RequestQueue(Cache cache, Network network, int threadPoolSize) {
        this(cache, network, threadPoolSize,
                new ExecutorDelivery(new Handler(Looper.getMainLooper()))); }

P/S: если вы хотите, чтобы строки BasicNetwork.logSlowRequests: HTTP response for request больше не отображались без увеличения NETWORK_THREAD_POOL_SIZE, нужно только прокомментировать (//) строку logSlowRequests... выше (когда ваше приложение использует Google volley как модуль - не файл jar, а не compile mcxiaoke... в build.gradle файле)

Надеюсь, что это поможет!

Ответ 3

public class JGet extends Request {
    private final Response.Listener listener;

    public JGet(final String url, List params,
                Response.Listener responseListener) {
        super(Request.Method.GET, NetUtils.getUrlWithParams(url, params), new Response.ErrorListener() {
            @Override
            public void onErrorResponse(VolleyError volleyError) {
                NetUtils.dealVolleyError(volleyError, url);
            }
        });
        this.listener = responseListener;
        this.setRetryPolicy(new DefaultRetryPolicy(20 * 1000, 0, 1.0f));
        LogUtils.e("request-start--->");
        LogUtils.e(url);
        LogUtils.e(params);
        LogUtils.e("request-start--->");
    }
}

установить время ожидания.

Ответ 4

Не пытайтесь использовать оператор require для подключения к вашей базе данных при отправке запроса в файл PHP с использованием volley. Я заметил тайм-аут только тогда, когда я использую что-то вроде (требуется "init.php" ) Но когда я напрямую помещал свою информацию о соединении с БД в тот же файл, все, кажется, работает нормально.

Ответ 5

request.setRetryPolicy (новый DefaultRetryPolicy (50000, 5, DefaultRetryPolicy.DEFAULT_BACKOFF_MULT))