2017-01-05 3 views
2

Ich verwende eine Volley singleton, um POST-Nachrichten an einen Server NanoHTTPD in Java zu senden. Die Nachrichten sind kurz und die Prozesszeit ist schnell und es gibt nicht mehr als 1 Nachricht gleichzeitig.Zufällige Verzögerungen mit Volley-Anfrage

Das Problem besteht darin, dass nach dem Zufallsprinzip einige Verzögerungen in der Warteschlange zur Verarbeitung der Anforderung auftreten, wodurch Ladezeiten von 3-4 Sekunden generiert werden. Der häufigste Fall ist die erste Nachricht (das ist kein Problem, ich denke, es gibt einige Instanzen) oder wenn ich mehr als 5-10 Sekunden nach jeder Nachricht warte. Aber wenn ich zum Beispiel 100 POST-Nachrichten mit 1 Sekunde Verzögerung verschicke, ist das kein Problem.

Ich habe den Server überprüft und es wird keine Anfrage generiert, so ist das Problem auf der Client-Seite.

In diesen Fällen die logcat Diesen:

D/Volley: [839] BasicNetwork.logSlowRequests: HTTP-Antwort für request = < [] http://192.168.2.8:8765 0x355fcdd NORMAL 1> [Lebensdauer = 4768], [size = 115], [rc = 200], [retryCount = 0]

Doing einig google logSlowRequests bedeutet nur, dass ... die Anforderungszeit in der verarbeiten nahm Client-Seite.

Eine andere Lösung zu versuchen ist, die threadPoolSize zu erhöhen, aber das hat nicht funktioniert. Immer die erste Anfrage braucht viel Zeit.

Dies ist der Singleton-Code:

public class VolleySingleton { 

    private static VolleySingleton mInstance; 
    private RequestQueue mRequestQueue; 
    private static Context mCtx; 
    private DiskBasedCache cache; 
    private BasicNetwork network; 

    /** 
    * @param context 
    */ 
    private VolleySingleton(Context context) { 
     mCtx = context; 
     mRequestQueue = getRequestQueue(); 
    } 

    /** 
    * @param context 
    * @return 
    */ 
    public static synchronized VolleySingleton getInstance(Context context) { 
     if (mInstance == null) { 
      mInstance = new VolleySingleton(context); 
     } 
     return mInstance; 
    } 

    /** 
    * @return 
    */ 
    public RequestQueue getRequestQueue() { 
     if (mRequestQueue == null) { 
      // Instantiate the cache 
      cache = new DiskBasedCache(mCtx.getCacheDir(), 1024 * 1024); // 1MB cap 
      // Set up the network to use HttpURLConnection as the HTTP client. 
      network = new BasicNetwork(new HurlStack()); 
      // getApplicationContext() is key, it keeps you from leaking the 
      // Activity or BroadcastReceiver if someone passes one in. 
      mRequestQueue = new RequestQueue(cache, network, 20); 
      mRequestQueue.start(); 
     } 
     return mRequestQueue; 
    } 

    /** 
    * @param req 
    * @param <T> 
    */ 
    public <T> void addToRequestQueue(Request<T> req) { 
     req.setRetryPolicy(new DefaultRetryPolicy(
       30000, 
       DefaultRetryPolicy.DEFAULT_MAX_RETRIES, 
       DefaultRetryPolicy.DEFAULT_BACKOFF_MULT)); 
     getRequestQueue().add(req); 
    } 

} 

Antwort

0

Hat eine tiefe debug und das Problem war der Server:

this.remoteHostname = !inetAddress.isLoopbackAddress() && !inetAddress.isAnyLocalAddress()?inetAddress.getHostName().toString():"localhost"; 

Diese erzeugen einen DNS-Lookup, die einige Sekunden dauern.

es ein Problem in der Bibliothek bereits GitHub Projekt hochgeladen ist:

https://github.com/NanoHttpd/nanohttpd/issues/396

Verwandte Themen