2012-06-15 5 views
5

Ich muss erneut versuchen, eine GWT-RPC-Anforderung zu senden, wenn sie fehlschlägt (jeder andere Antwortcode als HTTP 200). Die Gründe sind komplex, deshalb werde ich nicht näher darauf eingehen. Was ich bis jetzt habe, ist ich alle Anforderungsantworten an der gleichen Stelle wie folgt zu behandeln:Wie wird eine GWT-RPC-Anforderung erneut gesendet, wenn sie fehlschlägt (oder wie eine persistente RPC-Anforderung erstellt wird)?

// We override the RpcRequestBuilder.doSetCallback method and force your service to use it 
    // With this we can read the response headers if we need to. 
    ((ServiceDefTarget)serviceRPC).setRpcRequestBuilder(new RpcRequestBuilder() { 

     @Override 
     protected void doSetCallback(RequestBuilder rb, final RequestCallback callback) { 
      super.doSetCallback(rb, new RequestCallback() { 

       @Override 
       public void onResponseReceived(Request request, 
         Response response) { 
        httpResponseOkHandler(callback, request, response); 
       } 

       @Override 
       public void onError(Request request, Throwable exception) { 
        httpResponseErrorHandler(callback, request, exception); 
       } 
      }); 
     } 
    }); 

Also, mit httpResponseOkHandler Methode kann ich HTTP Ausfälle fangen. Aber gibt es eine Möglichkeit, die Anfrage "erneut zu versuchen", d. H., Versuchen Sie es erneut? Ich möchte die High-Level-Parameter der RPC-Anforderung nicht speichern, ich würde lieber den Anforderungsinhalt verwenden, der bereits gestreamt wurde und zum erneuten Senden bereit ist.

Irgendwelche Ideen?

Antwort

4

Nun, habe die Antwort selbst gefunden. Es ist also ziemlich nett. In stark belasteten Krankenhausumgebungen arbeiten Netzwerke oft unzuverlässig. Aus diesem Grund musste ich die RPC-Anfragen einige Male erneut senden, bevor ich aufgab. Hier ist die Lösung:

1- Setzen Sie den Builder für besondere Anforderungen, um alle Anfragenantworten abzufangen, aber behalten Sie den Request Builder bei.

2- Verwenden Sie jetzt den Request Builder, um die Anfrage so oft wie gewünscht zu senden. Eine großartige Sache ist, dass der Request-Builder bereits gesetzt wurde und Daten serialisiert wurden, was es unnötig macht, POJO-unserialisierte Daten zu speichern.

// We had some server HTTP error response (we only expect code 200 from server when using RPC) 
    if (response.getStatusCode() != Response.SC_OK) { 
     Integer requestTry = requestValidation.get(requestBuilder.getRequestData()); 
     if (requestTry == null) { 
      requestValidation.put(requestBuilder.getRequestData(), 1); 
      sendRequest(requestBuilder, callback, request); 
     } 
     else if (requestTry < MAX_RESEND_RETRY) { 
      requestTry += 1; 
      requestValidation.put(requestBuilder.getRequestData(), requestTry); 
      sendRequest(requestBuilder, callback, request); 
     } else { 
      InvocationException iex = new InvocationException("Unable to initiate the asynchronous service invocation -- check the network connection", null); 
      callback.onError(request, iex); 
     } 
    } else { 
     callback.onResponseReceived(request, response);   
    } 

Dies funktioniert gut für mich, verwenden Sie es auf eigene Gefahr!

+0

Was ist requestValidation? Ist es eine Karte? –

+0

Ja, ein einfacher MAP. Vielleicht nicht die eleganteste Lösung, wenn Sie etwas vorschlagen möchten, würde ich mich freuen, es zu betrachten. –

Verwandte Themen