OSLC call unresposnive when getting artifact information from DNG in 6.0.6.1
We are trying to create multiple artifacts in DNG using OSLC, we have seen a strange behavior after we upgraded our servers to 6.0.6.1 :
1. We used to get response body after the artifact got created earlier, now there is a blank response with 201 code. As a workaround we are able to get the location header and fetch information by hitting the uri value from the location header.
2. In case of multiple artifacts, the first time it works fine but for the second artifact , when the code hits the uri it just hangs there and doesn't get any response back, and the call is stuck there.
I request your support or any suggestions in this regard.
One answer
Hi Saksham
In response to POST to create an artifact I would expect you to get 201 - this means "success - created" - and the associated Location header gives the URL of the created artifact. I don't know if/why the response body has changed but the Location header was probably always there and should have been your way to locate the new artifact. See e.g. https://httpstatuses.com/201
> .. for the second artifact, "when the code hits the uri"
Do you mean that after the second POST (to create the second artifact) which returned 201 the GET for the 201 response Location header hangs with no response (i.e. and the server isn't responding to the GET?)
In your browser can you see this second created artifact?
If you kill your app and run it again does it once again create the first artifact then get stuck after the second? If so the server isn't stuck, and this is very likely to be a problem in your code - take a much closer look at the setup for the second POST and GET.
Have you tried tracing app<>server communication using e.g. Telerik Fiddler (Windows) or mitm (Linux) to see what is different about the second POST or second GET compared to the first?
Regards
Ian
Comments
Hi Ian,
Thanks for your response
>In response to POST to create an artifact I would expect you to get 201... that still remains same, The difference I have observed from this version is that the response body has changed, i.e, it is not there anymore.
> for the second artifact.. on tracing the GET call I observed that by locating the new artifact URI and trying to fetch the information the max connection per route as set by default in the JazzFormAuthClient is getting out of bounds. I am currently trying to increase the connection per route parameter for the Http client.