Wie Sie sich richtig JAX-RS 2.0-Client

Question

teilen sich ein wenig Kontext zu meinem Problem geben ...

ich eine Java EE Web-Anwendung haben (als UI/Client), die über Dienste für Daten-/Geschäftslogik zugreift eine REST-Schnittstelle, die die JAX-RS 2.0-Client-API (Resteasy-Implementierung) verwendet.

Zur Zeit injiziere ich eine neue JAXRS Client Instanz pro Anfrage mit einer RequestScoped CDI Bean, wobei die Client App mehrere Backend Ressourcen pro Anfrage aufrufen darf und ich den gleichen JAXRS Client für die gesamte Anfrage wiederverwende (obwohl ich gelesen habe irgendwo ist dies möglicherweise nicht korrekt, da ich möglicherweise den URI für jeden Aufruf ändere)

Die Dokumentation für JAXRS-Client scheint darauf hinzuweisen, dass der Client eine potenziell teure Operation ist und die App die Anzahl der von ihr erstellten Verbindungen begrenzen sollte. Es scheint sich auch zu widersprechen und schlägt vor, dass der Client geschlossen wird, sobald alle Anforderungen an ein bestimmtes WebTarget abgeschlossen sind. Die Client-Anwendung könnte möglicherweise Tausende von Benutzern gleichzeitig unterstützen, so dass das Erstellen und Zerstören von Tausenden von "teuren Clients" nicht der richtige Ansatz zu sein scheint. Daher denke ich, dass ein geteilter Client-Pool besser geeignet ist, aber es scheint nicht zu sein irgendwelche Informationen darüber, wie dies erreicht werden sollte.

Alle Beispiele scheinen zu zeigen, einen neuen Client für die Anfrage zu erstellen und a) nach oder b) schließen, aber nicht wirklich erklären, was bei einer zweiten Anfrage passiert.

Können Sie uns helfen, Ihnen einige Antworten auf die Frage zu geben, wie Sie dies lösen könnten, oder Informationen darüber, welche Vorgehensweise für diesen Ansatz am besten geeignet ist?

Danke.

Answer 1

Der einzige "Best-Practice" -Rat, den ich seen zur Vermeidung entweder schlechter Leistung oder schlechter Speicherauslastung mit einem JAX-RS 2.0-Client habe, bezieht sich auf die Jersey-Implementierung von Jax-RS und ist daher möglicherweise nicht gültig Ruhig schlafen. Ich vermute jedoch, dass die beiden Implementierungen ähnlich genug sind, dass der Rat tragbar ist.

Grundsätzlich mein Verständnis ist

• Verwendung ClientBuilder eine kleine Anzahl von vollständig konfigurierten Client-Instanzen zu erstellen - Sie verschiedene Kunden mit unterschiedlichen Konfigurationen benötigen (z Serialisierung/Deserialisierung Anbieter) in verschiedenen Situationen. So etwas sollte wahrscheinlich bei der Anwendungsinitialisierung oder ähnlichen "seltenen" Ereignissen passieren.
• teilen Sie jede vollständig konfigurierte Clientinstanz unter Klassen mit denselben Konfigurationsanforderungen. Sie können beispielsweise Ihrem DI-Framework mitteilen, dass jede dieser Client-Instanzen als @Singleton definiert wird.
• Vermeiden Sie den Aufruf von Methoden auf Client-Instanzen, die die zugrunde liegende Konfiguration ändern. Beispiele sind Dinge wie register(Class<T> componentClass) - so ziemlich alles auf der javax.ws.rs.core.Configurable Schnittstelle.
• Jedes Instanzobjekt, das einen freigegebenen Client verwendet, kann (und sollte?) Eigene, private und nicht freigegebene WebTargets erstellen. Effektiv sind WebTargets, die @RequestScoped und nicht Clients sein sollten.
• Wie beim Client sollte jedoch bei Verwendung eines WebTargets vermieden werden, dass über die Schnittstellenmethoden javax.ws.rs.core.Configurable diddelt wird.

Danach ist es ziemlich einfach Segeln.