2010-07-18 6 views
5

Sono bloccato configurando Restlet per il mio codice lato client. Sto usando Restlet 2 e HttpClient 4. Ho aggiunto il jar dell'estensione e i jar HttpClient al percorso di build e sembra funzionare.Configurazione di HttpClient per l'utilizzo come client Restlet

Tuttavia, non so come configurarlo in dettaglio. Non creo alcun client manualmente, invece utilizzo le interazioni ClientResource s, che è l'unica parte in cui utilizzo direttamente il Restlet. L'istanziazione concreta dei clienti sembra essere nascosta nell'implementazione del framework. Ho trovato alcuni suggerimenti su come configurare i client, ma sono stati scritti tutti per Restlet 1.x.

Nel dettaglio, voglio configurare le seguenti parti:

  • Modificare l'User Agent per le richieste dei client. clientResource.getClientInfo().setAgent(…) non funziona.
  • Aumentare il numero di connessioni parallele per host.
  • Abilita connessioni permanenti e pooling per host. Ovviamente, Restlet finora crea una nuova connessione per ClientResource, che non è molto efficiente.

Naturalmente, ho già dato un'occhiata a HttpClientHelper, ma non so dove e come aggiungerlo. Ho già cercato la documentazione per questo, ma senza colpi.

Grazie per l'aiuto!

+2

Suggerirei di postare questa domanda sulla mailing list di Restlet-discuss (http://restlet.tigris.org/ds/viewForums.do). Restlet 2.0 dovrebbe essere rilasciato entro pochi giorni, quindi potrebbe valer la pena segnalare se c'è un bug. – Bruno

+0

Sono d'accordo con Bruno. Sarebbe bello vedere quali sono le riflessioni degli sviluppatori di Restlet su questo. Sei corretto sull'inefficienza del comportamento predefinito 'ClientResource' e il problema di sicurezza del thread lo esaspera. – laz

+0

Sembra che la domanda sia stata posta: http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2635381 – laz

risposta

4

Innanzitutto, per assicurarsi che il Restlet usi HttpClient di Apache per le connessioni, è necessario org.restlet.ext.httpclient.jar sul classpath. Secondo, stai passando un Context nel costruttore del tuo ClientResource? Se non è necessario:

final Context context = new Context(); 
    context.getParameters().set("maxConnectionsPerHost", "20"); 

    final ClientResource requestResource = new ClientResource(context, "http://localhost:8182/request"); 
    requestResource.getClientInfo().setAgent("Example-Client/1.0"); 

che cura l'impostazione che si interessa maxConnectionsPerHost Inoltre, chiamando setAgent lavorava come previsto per me.. Non sono sicuro di quale potrebbe essere il problema nella tua istanza.

Per quanto riguarda le connessioni persistenti, sembra che HttpClient si prenda cura di questo per voi. Restlet utilizza HttpClient's ThreadSafeClientConnManager descritto here. Cita il supporto per le connessioni persistenti a quel collegamento. Sembra che questo oggetto si prenderà cura dei tuoi problemi di pooling. Si vorrebbe riutilizzare la stessa istanza di ClientResource per approfittare di questo. Non sono al corrente del criterio di sicurezza del thread di ClientResource ma spero che sia thread-safe.

+0

Grazie per la risposta. Sfortunatamente, l'impostazione del programma utente ancora non funziona e http://www.restlet.org/documentation/2.0/jse/api/org/restlet/resource/ClientResource.html afferma che ClientResources non sono progettati per essere condivisi tra più thread, il che è davvero pessimo. –

+1

Dovrei aver appena letto il Javadoc! Ho trovato qualcosa di interessante che potrebbe non essere un effetto collaterale previsto dell'uso di 'ClientResource'. Dopo aver effettuato una richiesta con l'istanza 'ClientResource', i risultati di' requestResource.getNext() 'restituiranno l'oggetto' Client' utilizzato per eseguire la chiamata. È possibile salvare il riferimento a tale oggetto e riutilizzarlo in futuro 'ClientResources' fornendo a' setNext (Uniform next) '. Dal momento che il 'Client' incapsula tutti gli oggetti HttpClient si salverebbe sul ricreare tutti quegli oggetti. Non sono sicuro di quanto sarebbe un abuso tale approccio! – laz

+0

Questo trucco funziona effettivamente per alcune richieste simultanee. Se tuttavia il numero di richieste aumenta e ci sono molte più richieste rispetto alle connessioni, inizia a generare alcune eccezioni interne casualmente. Quindi preferirei una soluzione ufficiale. Tuttavia grazie per il tuo suggerimento. –