I'm using the Citrus framework to test Camel routes. I'm sending a request to the Camel-based application which in turn sends multiple requests in parallel to a SOAP server.
I'm trying to mock the SOAP server with Citrus using the parallel container. I use selectors to trigger the correct receive and send actions similar to the following example (the real code is a bit more complicated):
parallel().actions(
sequential().actions(
soap().server("soapService")
.receive()
.selector("xpath:local-name(/*)='exampleRequest1' AND xpath://ns1:id/text()='123'")
.payload(new ClassPathResource("data/123/exampleRequest1.xml")),
echo("Received exampleRequest1"),
soap().server("soapService")
.send()
.payload(new ClassPathResource("data/123/exampleResponse1.xml")),
echo("Sent exampleResponse1"),
),
sequential().actions(
soap().server("soapService")
.receive()
.selector("xpath:local-name(/*)='exampleRequest2' AND xpath://ns1:id/text()='456'")
.payload(new ClassPathResource("data/456/exampleRequest2.xml")),
echo("Received exampleRequest2"),
soap().server("soapService")
.send()
.payload(new ClassPathResource("data/456/exampleResponse2.xml")),
echo("Sent exampleResponse2"),
),
...
)
Citrus does indeed receive the messages but it cannot reply. The error message of each parallel thread is:
13:35:36.121 [Thread-22] ERROR com.consol.citrus.container.Parallel - Parallel test action raised error
java.lang.IllegalArgumentException: Failed to find reply channel for message correlation key: citrus_message_id = 'c37eb703-4fb3-4c34-98f8-9cf8ee0414a1'
at org.springframework.util.Assert.notNull(Assert.java:198)
at com.consol.citrus.channel.ChannelSyncConsumer.send(ChannelSyncConsumer.java:73)
at com.consol.citrus.actions.SendMessageAction.doExecute(SendMessageAction.java:125)
…
Important: The citrus_message_id that each thread is looking for is always the same but should be different. So if one of the send actions actually succeeds, it's usually sending with the wrong reply channel.
What could be the problem here? Is this a bug or am I missing something?
Thank you very much!
The parallel container causes the problems here. But you can safely remove the parallel container when using selectors in receive actions. It should work fine for you once you have removed the parallels
Related
I am having intermittent connectivity problems with an old legacy api that sometimes causes a
'BackendConnectionFailure at transfer-response' error to be returned from Azure API Management. From my experience retrying the request to the legacy api is usually successful. I have a retry policy similar to the below that is checking for 5xx status codes, however, the retries do not seem to take place.
<retry
condition="#(context.Response.StatusCode == 500)"
count="10"
interval="10"
max-interval="100"
delta="10"
first-fast-retry="false">
<forward-request buffer-request-body="true" />
</retry>
Upon further research Application Insights seems to indicate that the Backend Dependency has a call status = false, but a Result Code = 200.
Is there any way to detect this condition so that a retry takes place, or any other policies that can be used?
In your policy above retry covers only receival of response status code and headers from backend. Response body is not proactively read by APIM and instead transferred directly from backend to client piece by piece. That is what "Transfer response" means. By that time all your policies have already completed.
One way to avoid that is to proactively buffer response from backend at APIM side. Try adding as the first thing in outbound:
<set-body>#(context.Response.Body.As<byte[]>())</set-body>
I'm creating a Forge application which needs to get version information from a BIM 360 hub. Sometimes it works, but sometimes (usually after the code has already been run once this session) I get the following error:
Exception thrown: 'Autodesk.Forge.Client.ApiException' in mscorlib.dll
Additional information: Error calling GetItem: {
"fault":{
"faultstring":"Unexpected EOF at target",
"detail": {
"errorcode":"messaging.adaptors.http.flow.UnexpectedEOFAtTarget"
}
}
}
The above error will be thrown from a call to an api, such as one of these:
dynamic item = await itemApi.GetItemAsync(projectId, itemId);
dynamic folder = await folderApi.GetFolderAsync(projectId, folderId);
var folders = await projectApi.GetProjectTopFoldersAsync(hubId, projectId);
Where the apis are initialized as follows:
ItemsApi itemApi = new ItemsApi();
itemApi.Configuration.AccessToken = Credentials.TokenInternal;
The Ids (such as 'projectId', 'itemId', etc.) don't seem to be any different when this error is thrown and when it isn't, so I'm not sure what is causing the error.
I based my application on the .Net version of this tutorial: http://learnforge.autodesk.io/#/datamanagement/hubs/net
But I adapted it so I can retrieve multiple nodes asynchronously (for example, all of the nodes a user has access to) without changing the jstree. I did this to allow extracting information in the background without disrupting the user's workflow. The main change I made was to add another Route on the server side that calls "GetTreeNodeAsync" (from the tutorial) asynchronously on the root of the tree and then calls it on each of the returned children, then each of their children, and so on. The function waits until all of the nodes are processed using Task.WhenAll, then returns data from each of the nodes to the client;
This means that there could be many api calls running asynchronously, and there might be duplicate api calls if a node was already opened in the jstree and then it's information is requested for the background extraction, or if the background extraction happens more than once. This seems to be when the error is most likely to happen.
I was wondering if anyone else has encountered this error, and if you know what I can do to avoid it, or how to recover when it is caught. Currently, after this error occurs, it seems that every other api call will throw this error as well, and the only way I've found to fix it is to rerun the code (I use Visual Studio so I just rerun the server and client, and my browser launches automatically)
Those are sporadic errors from our apigee router due to latency issues in the authorization process that we are currently looking into internally.
When they occur please cease all your upcoming requests, wait for a few minutes and retry again. Take a look at stuff like this or this to help you out.
And our existing reports calling out similar errors seem to point to concurrency as one of the factors leading up to the issue so you might also want to limit your concurrent requests and see if that mitigate the issue.
How to fix status code 409 for translate job.
There are two types of problems I am facing.
1. Sometimes API returns error status code 409(conflict)
2. Sometimes it continuously gives in progress status and never completes or fails even.
Once any of the above error occurs, any subsequent job requests starts failing with error code 409.
We are trying node js API for translating job using following code.
let translateResult = derivativesAPI.translate(job, { 'xAdsForce': true }, forgeSvc.requestOAuth2TwoLeggedOBJ(), accessToken);
First try to delete manifest for the stuck/pending request file,
If that doesn't works , last option is to delete the bucket with pending/stuck translation request and then try again.
As per documentation, the 409 means:
The request conflicts with a previous request that is still in progress
As you mentioned a previous request failed, but is pending on our system and causes this conflict. Is that happening consistently with a file? Or random? When it fails (or hangs), what's the manifest? Finally, can you share a problematic URN?
EDIT: the file is working now and we'll keep investigating this.
We have completed all the steps as described in the hello-spinnaker example below.We have used the AWS spinnaker image to directly configure spinnaker in AWS.
www.spinnaker.io/docs/hello-spinnaker.
I am trying to create a sample pipeline as noted in the above example.But while I create trigger in the first step and select jenkins ,the jobs are not getting populated and am getting below error in browser.
GET http://localhost:8084/v2/builds/Jenkins/jobs 429 (Too Many Requests)
The actual issue looks like while retrofit is trying to map the response from jenkins getjobs into the JobList class its finding an attribute _class in jenkins response xml and which is not present in JobList groovy class.Below is how we tried finding the issue
1)Login to AWS Spinnaker instance
2)Gate service is exposed at port 8084.
curl http://localhost:8084/v2/builds/Jenkins/jobs.
{"failureCause":"retrofit.RetrofitError: 429 Too Many Requests","error":"Too Many Requests","message":"429 Too Many Requests","status":429,"url":"http://localhost:8088/jobs/Jenkins","timestamp":1462793944530}
3)Igor service is exposed at port 8088.
curl http://localhost:8088/jobs/Jenkins
{"fallbackException":"java.lang.UnsupportedOperationException: No fallback available.","failureType":"COMMAND_EXCEPTION","failureCause":"retrofit.converter.ConversionException: org.simpleframework.xml.core.AttributeException: Attribute '_class' does not have a match in class com.netflix.spinnaker.igor.jenkins.client.model.JobList at line 1","error":"Hystrix Failure","message":"jenkins-Jenkins-getJobs failed and no fallback available.","status":429,"timestamp":1462793896853}
When I check in the igor logs,there are few exceptions which are occuring during the getprojects by jenkins poll
Caused by: retrofit.converter.ConversionException: org.simpleframework.xml.core.AttributeException: Attribute '_class' does not have a match in class com.netflix.spinnaker.igor.jenkins.client.model.ProjectsList at line 2
at retrofit.converter.SimpleXMLConverter.fromBody(SimpleXMLConverter.java:38)
at retrofit.RestAdapter$RestHandler.invokeRequest(RestAdapter.java:367)
... 39 common frames omitted
Caused by: org.simpleframework.xml.core.AttributeException: Attribute '_class' does not have a match in class com.netflix.spinnaker.igor.jenkins.client.model.ProjectsList at line 2
4)Connect to jenkins and get the jobs as its being done in spinnaker code https://github.com/spinnaker/igor/blob/master/igor-web/src/main/groovy/com/netflix/spinnaker/igor/jenkins/client/JenkinsClient.groovy
resp = requests.get('http://jenkinserverip:8080/api/xml?tree=jobs[name,jobs[name,jobs[name,jobs[name,jobs[name,jobs[name,jobs[name,jobs[name,jobs[name,jobs[name]]]]]]]]]]',auth=('admin','password'))
print resp.text
<hudson _class='hudson.model.Hudson'><job _class='hudson.model.FreeStyleProject'><name>Hello Build</name></job><job _class='hudson.model.FreeStyleProject'><name>Hello Poll</name></job></hudson>
So as the jenkins response is having the _class attribute ,retrofit is throwing an error at this line http://grepcode.com/file/repo1.maven.org/maven2/com.squareup.retrofit/retrofit/1.9.0/retrofit/RestAdapter.java#383
I wanted to see how can we quickly fix this as it looks like some version in compatibility of jenkins.
I'm seeing a similar issue in spinnaker 1.8.5. I had to reformat the jenkins url from myjenkins.server.com:8080 to http://myjenkins.server.com/ and it corrected the issue.
this is a bug around the jenkins api in later version. I believe 2.2 is the last compatible version, we run 1.6 internally.
Mule documentation states that catch-exception-strategy is similar to java catch block. But unfortunately, the payload is consumed (message is consumed); from the catch block the payload is lost (unlike a java method where you can access the method input parameters from a catch/finally block).
The problem with this design is that at any instance, (from the catch strategy flow) it is impossible to know the error and last known enriched payload which was used (which caused the error?). This complicates auditing of data which caused the error.
Suppose if there is a flow with 10 message processors, it becomes tedious to identify the message processor which threw error.
I can see 2 workarounds regarding the payload:
1) After the inbound endpoint, push the payload to a flow variable before every message processor (again another disadvantage is what happens to the Inbound properties and attachments?)
2) Use Rollback exception strategy with zero attempts (the transaction will be rolled back), and original input message may be available. (drawback: it is difficult to introspect on why the error happend and on which message processor - example: I may have 5 or 6 DB processors)
The reason why this becomes important is supporting an ESB application in production becomes easier.
For example, from the catch-block if we are able to pipe the payload and exception details (linked to a single UID), then you can run a log monitor tool, push it to a real time dashboard for monitoring purpose/raise Alerts. The same approach can be uniformly applied to all the applications/flows and java components, etc.
MMC is weak in this area - for example, if you want to supress Alerts from a batch job after 5 occurrences, MMC cannot do it.
My questions are:
1) Is there any reason on why the payload is made unavailable?
Possible workaround is to push (last known data) to another variable as part of message called originalPayload or originalInboundProperties?
2) Any other straight forward way of piping the exception and payload to an appender (instead of workarounds)?
Ananth Krishnan (WHISHWORKS.com)