Thanks :). Sadly this doesn't make any difference :(. Still two requests...
Regards, Veit Gesendet: Montag, 27. April 2015 um 17:55 Uhr Von: "Sergey Beryozkin" <[email protected]> An: [email protected] Betreff: Re: Aw: Re: Re: CXF JAX-RS client proxy and duplicate requests under load Sure, use JAXRSClientFactoryBean instead, JAXRSClientFactoryBean bean = new JAXRSClientFactoryBean(); bean.setAddress(...); bean.setServiceClass(...); bean.setThreadSafe(true); bean.setUserName(...); bean.setPassword(...); SomeClass proxy = bean.create(SomeClass.class); Cheers, Sergey On 27/04/15 16:52, Veit Guna wrote: > Sure, but I can't find a suitable ctor on JAXRSClientFactory for specifiying > threadSafety AND username/password. > Could you give me a hint :)? > > Thanks. > > > > Gesendet: Montag, 27. April 2015 um 17:34 Uhr > Von: "Sergey Beryozkin" <[email protected]> > An: [email protected] > Betreff: Re: Aw: Re: CXF JAX-RS client proxy and duplicate requests under load > Hi > Can you actually set a threadSafe flag on the factory before creating a > proxy ? > If you have a proxy reused by multiple threads and invoking multiple > methods on it there are likely to be some side-effects. > I'm not 100% yet that is the cause of the problem but I;d like you to > confirm that you are seeing the same problem even of you set a flag > > Thanks, Sergey > > On 27/04/15 16:31, Veit Guna wrote: >> Hi Sergey. >> >> I've tested some more. It seems that it is not only related to DELETE >> requests. >> I've isolated the problem into the following: >> >> - created an endpoint that simply takes an ID and stores it in a HashSet >> - if an entry already exists, it fails with an Exception (to demonstrate >> duplicate requests) >> - the endpoint always returns 404 >> - the test method (50 parallel threads, 50 invocations) >> - loops 10 times over: >> - performs a GET request to the endpoint using a newly generated uuid, >> within a try catch NotFoundException block. >> - performs a 2nd GET request using a new uuid, within a try catch >> NotFoundException block >> >> If all goes well, the test should be ok. >> But in my case, the same request (same UUID) came in 5 times and returned >> HTTP 500 (Exception due to duplicate UUIDs). >> >> That means, that if you have 2 invocations on a proxy, and the 2nd returns >> an Exception (e.g. NotFound) , it seems to send one of the requests again to >> the server. >> >> Can you confirm that behavior? >> >> Thanks >> Veit >> >> >> >> >> >> Gesendet: Montag, 27. April 2015 um 13:25 Uhr >> Von: "Sergey Beryozkin" <[email protected]> >> An: [email protected] >> Betreff: Re: CXF JAX-RS client proxy and duplicate requests under load >> Hi >> >> So even though the client proxy calls delete() only once you still see a >> DELETE request coming twice to the server. >> The initial question: Do you observe it for delete() only ? >> >> Thanks, Sergey >> >> >> >> On 27/04/15 11:28, Veit Guna wrote: >>> Hi. >>> >>> I'm using Apache CXF 3.0.4 in client JAX-RS proxy mode to access my >>> services on the server via annotated server interfaces. >>> Under normal operation, this works so far. >>> >>> Now, I've created a testcase that: >>> >>> - create a proxy with JAXRSClientFactory.create() >>> - creates 10 resources >>> - gets the 10 resources >>> - updates the 10 resources >>> - deletes the 10 resources. >>> >>> All above sequentially executed. Works when simply executed. >>> >>> Now I've configured TestNG to execute this test method with 50 threads and >>> 50 invocations concurrently. >>> Every now and then, it happens that the testcase fails with an HTTP 500 >>> error. >>> >>> I've checked the server logs and I can see, that a DELETE request for the >>> same resource comes in twice in >>> a distance of approx. 20 msecs. Of course, only one request succeeds, the >>> other fails. >>> >>> I've created logging on the testcase client side and I can confirm, that >>> delete() is only called once on >>> the CXF client proxy. So I'm wondering, why the client generates two >>> requests. Any idea what is happening there? >>> >>> I also enabled the CXF logging on client side via cxf.xml and I can see: >>> >>> - DELETE request is send (ID: 1779) >>> - Response HTTP 500 is returned (ID: 1779) >>> - DELETE request is send? (ID: 1779 - SAME id?! Logged as "Inbound Message") >>> - No response. No further ID 1779. >>> >>> The server side logging looks like this >>> >>> - DELETE comes in (thread 437) >>> 20ms later >>> - DELETE comes in (thread 521) >>> 2secs later >>> - thread 521 completes successfully with HTTP 204. >>> - thread 437 throws HTTP 500. >>> >>> What I'm wondering is, how the order gets mixed up. Any idea how that can >>> happen? >>> >>> Here are detailed extractions from the logs: >>> >>> --cut here-- >>> ############ >>> Client side: >>> ############ >>> >>> 11:31:16,662 INFO [] [LoggingOutInterceptor:250] - Outbound Message >>> --------------------------- >>> ID: 1779 >>> Address: >>> http://localhost:8080/someservice/api/1/tenants/6a4322df-ad20-41b7-a5c9-908cadc509f5/repositories/f7c21bad-6743-4bed-916c-0b58d876204e/entries/46f069fa-c6a2-41cc-9dbc-ac5a2faffcfb >>> Http-Method: DELETE >>> Content-Type: application/xml >>> Headers: {Content-Type=[application/xml], Accept=[text/plain], >>> Authorization=[Basic ZmlsZW5zaGFyZTpzZWNyZXQ=]} >>> ... >>> ... >>> -------------------------------------- >>> 11:31:18,776 INFO [] [LoggingInInterceptor:250] - Inbound Message >>> ---------------------------- >>> ID: 1779 >>> Response-Code: 500 >>> Encoding: ISO-8859-1 >>> Content-Type: application/json >>> Headers: {connection=[close], Content-Length=[308], >>> content-type=[application/json], Date=[Mon, 27 Apr 2015 09:31:18 GMT], >>> Server=[Apache-Coyote/1.1]} >>> Payload: { >>> -------------------------------------- >>> 11:31:18,776 INFO [] [LoggingInInterceptor:250] - Inbound Message >>> ---------------------------- >>> ID: 1779 >>> Address: >>> http://localhost:8080/someservice/api/1/tenants/6a4322df-ad20-41b7-a5c9-908cadc509f5/repositories/f7c21bad-6743-4bed-916c-0b58d876204e/entries/46f069fa-c6a2-41cc-9dbc-ac5a2faffcfb >>> Http-Method: DELETE >>> Content-Type: application/xml >>> Headers: {Content-Type=[application/xml], Accept=[text/plain], >>> Authorization=[Basic ZmlsZW5zaGFyZTpzZWNyZXQ=]} >>> >>> >>> ############ >>> Server side: >>> ############ >>> >>> Apr 27, 2015 11:31:16 AM org.glassfish.jersey.filter.LoggingFilter log >>> INFO: 33572 * Server has received a request on thread http-bio-8080-exec-437 >>> 33572 > DELETE >>> http://localhost:8080/someservice/api/1/tenants/6a4322df-ad20-41b7-a5c9-908cadc509f5/repositories/f7c21bad-6743-4bed-916c-0b58d876204e/entries/46f069fa-c6a2-41cc-9dbc-ac5a2faffcfb >>> 33572 > accept: text/plain >>> 33572 > authorization: Basic something= >>> 33572 > cache-control: no-cache >>> 33572 > connection: keep-alive >>> 33572 > content-type: */* >>> 33572 > host: localhost:8080 >>> 33572 > pragma: no-cache >>> 33572 > user-agent: Apache CXF 3.0.4 >>> >>> 20ms between them >>> >>> Apr 27, 2015 11:31:16 AM org.glassfish.jersey.filter.LoggingFilter log >>> INFO: 33573 * Server has received a request on thread http-bio-8080-exec-521 >>> 33573 > DELETE >>> http://localhost:8080/someservice/api/1/tenants/6a4322df-ad20-41b7-a5c9-908cadc509f5/repositories/f7c21bad-6743-4bed-916c-0b58d876204e/entries/46f069fa-c6a2-41cc-9dbc-ac5a2faffcfb >>> 33573 > accept: text/plain >>> 33573 > authorization: Basic something= >>> 33573 > cache-control: no-cache >>> 33573 > connection: keep-alive >>> 33573 > content-type: */* >>> 33573 > host: localhost:8080 >>> 33573 > pragma: no-cache >>> 33573 > user-agent: Apache CXF 3.0.4 >>> >>> >>> Apr 27, 2015 11:31:18 AM org.glassfish.jersey.filter.LoggingFilter log >>> INFO: 33654 * Server responded with a response on thread >>> http-bio-8080-exec-521 >>> 33654 < 204 >>> >>> >>> Apr 27, 2015 11:31:18 AM org.glassfish.jersey.filter.LoggingFilter log >>> INFO: 33669 * Server responded with a response on thread >>> http-bio-8080-exec-437 >>> 33669 < 500 >>> 33669 < Content-Type: application/json >>> { >>> someerror json >>> } >>> --cut here-- >>> >>> Thanks. >>> Veit >>> >> >> > > -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com[http://sberyozkin.blogspot.com]
