I'm wonder what is the purpose of exception parameter that we can pass to
HealthCheckResult.Unhealthy("Message", exception);
When this result is used in health-check endpoint only message and status are used and no info from exception?
An Exception representing the exception that was thrown when checking for status. Optional.
https://learn.microsoft.com/en-us/dotnet/api/microsoft.extensions.diagnostics.healthchecks.healthcheckresult.unhealthy?view=dotnet-plat-ext-3.0
Here's a good explanation on how to use it: https://blog.elmah.io/asp-net-core-2-2-health-checks-explained/
Related
Env: Springboot-2.0.7.RELEASE (embedded tomcat-8.5.35), JDK-1.8.0_181, micrometer-registry-prometheus-1.0.8
Desc: using #Timed on controller method and WebMvcMetricsFilter with custom WebMvcTagsProvider.
Demo project: https://github.com/kenix/resp-mix
If PrometheusMeterRegistry already created a meter with a set of tags, it won't create another meter with same name and a set of different tags. It throws IllegalArgumentException with the aforementioned reason. This happens after the normal processing of request, which is successful (response now has the converted JSON). The exception isn't caught in spring's WebMvcMetricsFilter (i.e. catch the exception in its catch-clause. BTW, ControllerAdvice doesn't help), but is caught by tomcat's StandardHostValve, which renders his own error message (it cannot know where this exception is from) into response too. This leads to an illegal JSON as the rendered result.
Question 1: should WebMvcMetricsFilter catch and handle this Exception thrown by PrometheusMeterRegistry and not throw it further up?
Question 2: have seen that exception in filter chain before hitting the actual processing is handled as expected. What about exception after a successful actual processing? Any references?
To trigger this case:
curl -i localhost:8080/hi/foo/there
curl -i localhost:8080/hi/blah/there
Question 1: No, WebMvcTagsProvider handles HTTP Exceptions.
Question 2: Try using ControllerAdvice and catch the IllegalArgumentException there.
i would like to route my http:request to my main ( or secondary ) error handler in Anypoint Studio 7
i does not seem to have a clear way of doing it.
And the documentation does not have guideline for this specific case.
in my case is necessary, i need to know and send a signal to another service and communicate the error response, like: connection_timeout
You can catch the errors you want using an error-handler in your flow where you are executing the http:request. if you do not catch the error, it will bubble up to the calling flow and so on. If no error-handler is configured, the default mule one will be used which just logs the message basically.
In Mule 4 you can catch all errors in your flow like so:
<flow name="retrieveMatchingOrders">
<http:request config-ref="customersConfig" path="/customer">
</http:request>
<error-handler>
<on-error-continue>
<!-- error handling logic -->
</on-error-continue>
</error-handler>
</flow>
An on-error-continue will execute and use the result of the execution, as the result of its owner (as if the owner had actually completed the execution successfully). Any transactions at this point would be committed as well
So in there, you can set the payload to your desired message to be returned etc.
There also an on-error-propogate handler and a try scope, more information on those are available here: https://docs.mulesoft.com/mule-runtime/4.1/intro-error-handlers
All errors thrown in Mule contain meta-data including a TYPE. If you need to catch specific HTTP Errors you can configure your error-handler like so:
<error-handler>
<on-error-continue type="HTTP:TIMEOUT">
<!-- error handling logic -->
</on-error-continue>
</error-handler>
Here is a list of all specific HTTP: errors thrown by the HTTP module:
HTTP:UNSUPPORTED_MEDIA_TYPE
HTTP:CONNECTIVITY
HTTP:INTERNAL_SERVER_ERROR
HTTP:METHOD_NOT_ALLOWED
HTTP:NOT_ACCEPTABLE
HTTP:TOO_MANY_REQUESTS
HTTP:SERVICE_UNAVAILABLE
HTTP:CLIENT_SECURITY
HTTP:FORBIDDEN
HTTP:UNAUTHORIZED
HTTP:RETRY_EXHAUSTED
HTTP:NOT_FOUND
HTTP:BAD_REQUEST
HTTP:PARSING
HTTP:TIMEOUT
HTTP:SECURITY
Each module's documentation should contain all specific error types thrown by that module. Here is the HTTP one example:
https://docs.mulesoft.com/connectors/http/http-documentation#throws
And here is a full list of core error types you can catch like EXPRESSION for example:
https://docs.mulesoft.com/mule-runtime/4.1/mule-error-concept
We wrappered an existing queue with the extended functionality. Messages are able to be put on the queue, and we see the message body being stored on S3.
However, when the message is consumed we get the following stack trace:
com.amazonaws.services.sqs.model.ReceiptHandleIsInvalidException: The input receipt handle is invalid. (Service: AmazonSQS; Status Code: 404; Error Code: ReceiptHandleIsInvalid; Request ID: ba9421e9-a9d2-56ba-8e17-70ff7190f05a)
at com.amazonaws.http.AmazonHttpClient.handleErrorResponse(AmazonHttpClient.java:1182)
at com.amazonaws.http.AmazonHttpClient.executeOneRequest(AmazonHttpClient.java:770)
at com.amazonaws.http.AmazonHttpClient.executeHelper(AmazonHttpClient.java:489)
at com.amazonaws.http.AmazonHttpClient.execute(AmazonHttpClient.java:310)
at com.amazonaws.services.sqs.AmazonSQSClient.invoke(AmazonSQSClient.java:2419)
at com.amazonaws.services.sqs.AmazonSQSClient.changeMessageVisibility(AmazonSQSClient.java:485)
at com.amazonaws.services.sqs.AmazonSQSClient.changeMessageVisibility(AmazonSQSClient.java:1692)
at com.amazon.sqs.javamessaging.AmazonSQSExtendedClientBase.changeMessageVisibility(AmazonSQSExtendedClientBase.java:1376)
Which happens when we attempt to change the visibility. Is that not supported?
sqsExtended.changeMessageVisibility(queueUrl, message.getReceiptHandle(), visibilityTimeout);
The answer is that this hasn't been implemented, nor does it try to warn you by throwing an exception when calling the method. There doesn't seem to be a reason to not be implemented, looking at the source code, it would be straightforward.
For our case, we are okay with relaying on the queue default value for this parameter and not setting each individually.
I've built an integration with Rally using the SOAP API so that when I target a bug in bugzilla, a user story is created and scheduled in the proper release. It also work in update, so if I just update the target the US will be associated to the specified release in Rally.
It has been working for a while, but now it seems not to work anymore.
I get the following error:
org.xml.sax.SAXException: Invalid element in com.rallydev.webservice.v1_28.domain.OperationResult - Object
at org.apache.axis.encoding.ser.BeanDeserializer.onStartChild(BeanDeserializer.java:258)
at org.apache.axis.encoding.DeserializationContext.startElement(DeserializationContext.java:1035)
at org.apache.axis.message.SAX2EventRecorder.replay(SAX2EventRecorder.java:165)
at org.apache.axis.message.MessageElement.publishToHandler(MessageElement.java:1141)
at org.apache.axis.message.RPCElement.deserialize(RPCElement.java:236)
at org.apache.axis.message.RPCElement.getParams(RPCElement.java:384)
at org.apache.axis.client.Call.invoke(Call.java:2467)
at org.apache.axis.client.Call.invoke(Call.java:2366)
at org.apache.axis.client.Call.invoke(Call.java:1812)
at com.rallydev.webservice.v1_28.service.RallyServiceSoapBindingStub.update(RallyServiceSoapBindingStub.java:1166)
I updated to the latest API, but not luck.
Stefano,
This is a known issue in Rally and we expect it will be corrected this Saturday (3Dec11). If you need to get the code running right away, you can catch the thrown exception by editing the generated code.
As long as the SAX exception is caught, it does not prevent updates from actually succeeding. A couple customers have been able to workaround the mismatched return value by wrapping the update code and/or calls to the Rally service in a try/catch block similar to an example here on a Task:
try {
OperationResult operationResult = rallyService.update(myTask);
} catch (Exception e) {
System.out.println("Rally SAX Exception encountered");
}
Sorry for the inconvenience.
Mark
Solution:
A bit of tracing showed the CommunicationException was being thrown because there was an issue with my exception T not serializing correctly; because, two layers deep, I had an anonymously typed object, which was unserializable. Removing it and bubbling up the changes appeared to fix it. There was somethinge else small I did before that, but I can't remember for the life of me what it was, only that it wasn't done in the config.
I was getting messages from my traces such as:
Type 'RebuiltWCFService.Requests.HelloWorldRequest' with data contract name 'HelloWorldRequest:http://schemas.datacontract.org/2004/07/RebuiltWCFService.Requests' is not expected.
Consider using a DataContractResolver or add any types not known statically to the list of known types - for example, by using the KnownTypeAttribute attribute or by adding them to the list of known types passed to DataContractSerializer.
Original post
I've encountered a seemingly strange issue today that I just cant't find an answer to!
The problem: my service is throwing a CommunicationException when I throw a FaultException! It does not do this if I don't throw an exception.
In my service, I'm properly defining the fault contracts:
[OperationContract]
[FaultContract(typeof(Faults.HelloWorldFault))]
Responses.HelloWorldResponse HelloWorld(Requests.HelloWorldRequest parameter);
Then under error conditions I'm throwing an exception of the correct type:
if (_errors.Count() > 0)
{
Faults.HelloWorldFault fault = new Faults.HelloWorldFault(_errors);
throw new FaultException<Faults.HelloWorldFault>(fault, new FaultReason("There are one or more errors in the request. Check the 'Errors' property for more detaisl"));
}
And then I'm catching it on the client end:
try
{
response = client.HelloWorld(new BasicService.HelloWorldRequest() { Number = 49 });
client.Close();
Console.WriteLine(String.Format("Response message: {0}, Response number: {1}", response.Message, response.Number));
}
catch (FaultException<BasicService.HelloWorldFault> ex)
{
...
}
That all seems OK to me, and like it should work. However, as soon as I go to test my error clauses (by providing bad data, such as a missing field), the whole thing dies on me. When I throw my FaultException, the service instead throws a CommunicationException with the message
An error occurred while receiving the HTTP response to http://localhost:8732/Design_Time_Addresses/RebuiltWCFService/Service1/.
This could be due to the service endpoint binding not using the HTTP protocol.
This could also be due to an HTTP request context being aborted by the server (possibly due to the service shutting down).
See server logs for more details.
Can anybody offer some insight on this one? I am using the basicHttp binding, and I've also tried it with wsHttp. I will post my config file upon request.
A FaultException is a child of CommunicationException. So there is nothing wrong in what's happening in your code.
If you are uncertain about what the exception is while handling, it is usually reported as CommunicationException. If you want to handle your specific exception in your own way, use the following structure.
try
{ ... }
catch (FaultException<MyDemoException> me)
{ ... }
catch (FaultException fe)
{ ... }
catch (CommunicationException ce)
{ ... }
catch (Exception ex)
{ ... }
In the above structure, Exception is parent of CommunicationException. CommunicationException is the parent of FaultException and so on.
System.Object
System.Exception
System.SystemException
System.ServiceModel.CommunicationException
System.ServiceModel.FaultException
System.ServiceModel.FaultException<TDetail>
System.ServiceModel.Web.WebFaultException<T>
Thanks guys, you helped me to understand the issue in a better way. My observation: I kept a List MyData - to hold any generic/dynamic collection, that was unable to serialize, so resulting to close the connection, so the communication exception.
When I removed the List from Fault Contract, and throw Fault style, it was clearly giving Fault contract exception, instead of communication exception.
Hope it helps,
HydTechie.
I ran into this problem because I had one or more breakpoints in the wrong place. I removed all breakpoints with Debug..Delete all Breakpoints (Ctrl-Alt-F9), and all of the CommunicationException exceptions disappeared and were replaced with the correct messages coming back.
Yes, the timeout is 60 seconds, so this never should have occurred, so it was probably some weird artifact of Visual Studio 2012.