Jersey-Ressource, die doppelte Anfragen von Jersey-Client empfängt

Question

Wir aktualisierten kürzlich von Jersey 1.x auf Jersey 2.22.1 auf Server und Clients. Wir sehen jetzt intermittierend Jersey wird zwei Anfragen machen/erhalten.

• Mit intermittierend meine ich jede 1 von mehreren tausend Anfragen.
• Dieses Problem ist bei Verwendung von Jersey 1.x nicht aufgetreten.
• Es ist mir nicht klar, wenn dies ein Problem auf der Client- oder Server-Seite ist.
• Auf der Clientseite nur das Protokoll zeigt eine einzige POST-Anforderung und Antwort (siehe unten Schnipsel)
• Auf der Serverseite das Protokoll zeigt zwei POST-Anforderungen und Antworten (siehe unten Schnipsel)

Ich bin in der Lage, es zu reproduzieren, indem Sie viele tausend Male über diese Client-POST-Anfrage looping. Jede Anfrage sendet einen eindeutigen "Namen", der auf dem Server erhalten bleibt. Ich weiß, dass wir eine doppelte Anfrage erhalten haben, wenn ich eine einmalige Constraint-Verletzung erhalte, die versucht, denselben "Namen" zweimal zu erhalten. Ich habe andere Abschnitte des Codes ausgeschlossen, da das Protokoll bestätigt, dass Jersey zwei POST-Anfragen für denselben "Namen" erhält

Ich habe die Ablaufverfolgungsprotokollierung im org.glassfish-Paket auf dem Server aktiviert und LoggingFilter() auf dem Client registriert .

Client-Show nur 1 POST-Anfrage und Antwort:

Jun 21, 2016 6:02:51 PM org.glassfish.jersey.filter.LoggingFilter log 
INFO: 8291 * Sending client request on thread main 
8291 > POST http://localhost:9797/my-webapp/v1/data-feeds/ 
8291 > Accept: application/json 
8291 > Content-Type: application/json 

Jun 21, 2016 6:02:51 PM org.glassfish.jersey.filter.LoggingFilter log 
INFO: 8291 * Client response received on thread main 
8291 < 200 
8291 < Cache-Control: no-cache, no-store, max-age=0, must-revalidate 
8291 < Content-Length: 181 
8291 < Content-Type: application/json 
8291 < Date: Wed, 22 Jun 2016 00:02:51 GMT 
8291 < Expires: 0 
8291 < Pragma: no-cache 
8291 < Server: Apache-Coyote/1.1 
8291 < Set-Cookie: JSESSIONID=CFF556E7FCDB5B1F644BA04603364DFD; Path=/my-webapp/; HttpOnly 
8291 < X-Content-Type-Options: nosniff 
8291 < X-Frame-Options: DENY 
8291 < X-XSS-Protection: 1; mode=block 

Server zeigt zwei Stellen für das gleiche 'name':

Jun 21, 2016 6:02:51 PM org.glassfish.jersey.filter.LoggingFilter log 
INFO: 8293 * Server has received a request on thread http-bio-9797-exec-21 
8293 > POST http://localhost:9797/my-webapp/v1/data-feeds/ 
8293 > accept: application/json 
8293 > authorization: Basic YWRtaW46bmltZGE= 
8293 > connection: keep-alive 
8293 > content-length: 181 
8293 > content-type: application/json 
8293 > host: localhost:9797 
8293 > user-agent: Jersey/2.22.1 (HttpUrlConnection 1.8.0_31) 

2016-06-21 18:02:51,964 [INFO] [c.m.c.r.r.MyResource] Received POST request /data-feeds with args [FeedData{name='pool4146'}] 
Jun 21, 2016 6:02:51 PM org.glassfish.jersey.filter.LoggingFilter log 
INFO: 8294 * Server has received a request on thread http-bio-9797-exec-97 
8294 > POST http://localhost:9797/my-webapp/v1/data-feeds/ 
8294 > accept: application/json 
8294 > authorization: Basic YWRtaW46bmltZGE= 
8294 > connection: keep-alive 
8294 > content-length: 181 
8294 > content-type: application/json 
8294 > host: localhost:9797 
8294 > user-agent: Jersey/2.22.1 (HttpUrlConnection 1.8.0_31) 

2016-06-21 18:02:51,978 [INFO] [c.m.c.r.r.MyResource] Received POST request /data-feeds with args [FeedData{name='pool4146'}] 
Jun 21, 2016 6:02:51 PM org.glassfish.jersey.filter.LoggingFilter log 

INFO: 8293 * Server responded with a response on thread http-bio-9797-exec-21 
8293 < 200 
8293 < Content-Type: application/json 

Jun 21, 2016 6:02:51 PM org.glassfish.jersey.filter.LoggingFilter log 
INFO: 8294 * Server responded with a response on thread http-bio-9797-exec-97 
8294 < 200 
8294 < Content-Type: application/json 

Lassen Sie mich wissen, ob es eine andere ist Konfigurationsinformationen, die hier relevant sein könnten. Wir verwenden Tomcat 7.x und Jackson für die Serialisierung/Deserialisierung

Answer 1

Ich bin mit dem gleichen Problem stecken und ich bin nicht in der Lage, dieses Problem zu replizieren. Haben Sie versucht, den ClientResponse-Stream zu schließen? Lass mich wissen, wie das funktioniert.

Client client = new Client(); 
WebResource resource = client.resource(restUrl); 
final ClientResponse response = resource.get(ClientResponse.class); 
response.close(); 

Answer 2

Dies scheint ein ähnlicher Fehler zu sein, den wir hatten. Und wir hatten viel Mühe, das zu beheben.

Wir hatten dies bei https://java.net/jira/browse/JERSEY-3254 ausgestellt und die Reparatur für diesen Zweck beigefügt. Grundsätzlich befindet es sich in HttpAuthenticationFilter und macht die Digest-Authentifizierung kaputt. Die Ergebnisse sind oft die falschen 401-Code- oder StreamClosed-Ausnahmen. Ich werde meine Lösung für diesen Beitrag nicht kopieren, ich denke, das JIRA-Problem wird nicht gelöscht.