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.
Related
I have this code in Scala:
logger.error("Repository does not exists or does not contains 'definitions' directory")
throw new FileNotFoundException("Repository does not exists or does not contains 'definitions' directory")
Should i write message twice? Or should i only log the error and throw empty exception?
It depends, use cases to use cases.
If your log statement is within dev-scope then there is no need to throw exception to the source/caller. you can log exception and silent it and return back useful message/code to source/caller.
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/
Having:
Velocity template or macro
some object
How to validate the object (#if) and fail (stop further processing) in a way that is easily tracable to the place of failure (like throwing exception in Java).
I am looking for something like this:
#if ( ! $context.treasureMap.containsKey('gold'))
#fail('no golden treasure here')
#end
Background
I am writing a maven site page. The velocity context is injected by maven and contains POM information. I want to test existence of some information from effective pom. When the information is not available, I want to fail.
Requirements
fail Velocity processing > fail site generation > fail maven build.
error message should lead to the place of failure so the site should be fixed
preferably no configuration (no extensions, just constructs/tools contained in plain Velocity)
Tried
Strict Reference Mode
Unwanted configuration, do not want to fail on every occasion.
#evaluate('#end') aka syntax error
(Chose #end as most descriptive to my intent) Basically what I want. Fails the processing and maven build but the error message does not lead back to failure location:
ParseException: Encountered "#end" at line 1, column 1..
You need to make a method call which produce exception.See explanation:
The only place where one could run into trouble within Velocity is if there is a call to a method which throws an exception during runtime. For example, this VTL defines a String $foo and then attempts to call its substring() method on it would throw an IndexOutOfBoundsException:
#set ($foo = "bar")
#set ($bar = $foo.substring(0,10))
When the exception is thrown, the parser will stop processing and throw that exception up the stack tree where it can be caught in the method that caused the parser to execute. At that point, the exception can be handled gracefully.
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.