I am using Azure Blob storage. Everything work fine, but sometime i get following error intermittently:
"$type": "System.Web.Http.HttpError, System.Web.Http",
"Message": "An error has occurred.",
"ExceptionMessage": "Exception of type 'System.OutOfMemoryException' was thrown.",
"ExceptionType": "System.OutOfMemoryException",
"StackTrace": " at Microsoft.WindowsAzure.StorageClient.Tasks.Task`1.get_Result()
at Microsoft.WindowsAzure.StorageClient.Tasks.Task`1.ExecuteAndWait()
at Microsoft.WindowsAzure.StorageClient.TaskImplHelper.ExecuteImplWithRetry(Func`1 impl, RetryPolicy policy)
at Microsoft.WindowsAzure.StorageClient.CloudBlobContainer.SetPermissions(BlobContainerPermissions permissions, BlobRequestOptions options)
It's really hard to recreate the issue on my local. Any solutions ?
The following Stack Overflow thread might help C# : Out of Memory exception. To summarize, if you haven't already, try changing your platform target to x64 and see if that helps.
There was memory leak in the application with Windsor IOC not releasing object for GC. That was the root problem for this error.
Related
I've a question regarding capture of "uncaught" exceptions, which appears with stack trace on System.err, circumventing logging configuration: All the other log messages appear properly formatted on System.out (JSON-formatted in my case). But this doesn't happen with Exceptions and stack traces "logged" to System.err!
I've recognized this to happen under at least two circumstances:
Asynchronous execution of tasks (HTTP requests in my case) via ExecutorService (as mentioned in "Scheduled Tasks" chapter). I've added #Retryable annotation to the method; but after all retries fail, "final" Exception thrown by last unsuccessful retry appears on System.err with its stack trace (the other ones thrown by earlier failed retries do not appear, seems they are caught by retry "mechanism" under the hood).
With Exceptions thrown by failed Health indicators (they are implemented by subclassing AbstractHealthIndicator).
I've tried implementing my own TaskExceptionHandler, replacing the default one (also mentioned in "Scheduled Tasks" chapter); and/or by adding System.setErr(System.out) in main method before building/setup of Micronaut Application Context. But nothing seems to help as my test cases attest.
Have I missed a chapter in Micronaut's documentation?
Thanks for any hints.
Regards
Christian
My wager is that Micronaut doesn't provide tools for setting a global uncaught exception handler because that's governed by the wider JRE. We've solved the problem in a few of our services with Thread.html#setDefaultUncaughtExceptionHandler by doing something like this at application startup:
Thread.setDefaultUncaughtExceptionHandler((t, e) -> logger.error("Uncaught exception", e));
Every once in a while, at random times my software crashes due to a an exception with this message:
"Additional information: The runtime has encountered a fatal error. The address of the error was at 0x72938d57, on thread 0xe34. The error code is 0xc0000005. This error may be a bug in the CLR or in the unsafe or non-verifiable portions of user code. Common sources of this bug include user marshaling errors for COM-interop or PInvoke, which may corrupt the stack.
If there is a handler for this exception, the program may be safely continued."
It is begin generated from the .net RSACryptoServiceProvider.Encrypt method.
To take a look at it refer to https://github.com/HadiModarres/MRelay/blob/master/ConsoleApplication9/EncryptedRelay.fs line 94
my question is why is this happening and what can I do to catch exceptions that are generated from unmanaged code like this
Reposting from comment:
rsa.Encrypt is not thread-safe.
Does anybody know how to print full stack trace on the Browser, when a Runtime Exception occurs in MULE..??
When a runtime Exception occurs, MULE throws a 500 Server Error to the client , but shows no details to the client. It prints the whole stack trace in Console or Log Files (like the following) :
Root Exception stack trace:
java.sql.SQLException: Invalid column name
at oracle.jdbc.driver.OracleStatement.getColumnIndex(OracleStatement.java:3677)
at oracle.jdbc.driver.OracleResultSetImpl.findColumn(OracleResultSetImpl.java:2749)
at oracle.jdbc.driver.OracleResultSet.getString(OracleResultSet.java:494)
+ 3 more (set debug level logging or '-Dmule.verbose.exceptions=true'
for everything)
Can i show the same stack Trace on the Browser (to the client)..??
And if possible , then also tell me how to switch ON or OFF printing of Stack Trace on Browser..??
(It may be possible that sometime in future , i dont want to show stack trace on browser)
Yes this is possible. I assume you are using a regular HTTP endpoint and this is a REST type service(?) If so, you can simply put a try/catch around the code causing the exception and return whatever text you want.
There are also exception strategies (http://www.mulesoft.org/documentation/display/MULE3USER/Error+Handling) for doing more sophisticated error handling, but it sounds like you are looking for the simple answer above.
If this doesn't answer your question, please provide more info about your mule config and the service that is raising the exception.
There is nothing out of the box in Mule to do that. You have to implement an exception handler that will format the stacktrace in the Message exception payload and return it to the caller.
In your case, the HTTP transport has a particularity that can be found in the HttpMessageReceiver code:
try
{
conn.writeResponse(processRequest(request));
}
catch (Exception e)
{
...
conn.writeResponse(buildFailureResponse(request.getRequestLine().getHttpVersion(), httpStatus, e.getMessage()));
This means that when an exception crops-up to the top level, the creation of the failure message response is not customizable: you get this pretty technical message back and that is all.
I see two options to solve your problem:
sub-class HttpMessageReceiver and make the response message customizable in your version,
drop the HTTP transport in favor of the Jetty one (look at the bookstore example) and customize the response error messages at the web container level.
I have already spent a few hours to resolve this error. The weird thing is when I use this libraries independently, it works absolutely fine but when I integrate them with my ASP .NET MVC website, it start throwing the following exception. I have also used MachineKeySet flag based on suggestion here but still no luck. Could anyone please help me to get rid of this exception. Thanks.
An internal error occurred.
Description: An unhandled exception
occurred during the execution of the
current web request. Please review the
stack trace for more information about
the error and where it originated in
the code.
Exception Details:
System.Security.Cryptography.CryptographicException:
An internal error occurred.
Source Error:
Line 194: if
(string.IsNullOrEmpty(p12FilePassword))
Line 196: certificate = new X509Certificate2(p12FileBytes, "", X509KeyStorageFlags.MachineKeySet);
Line 197: else
I found the solution here. Looks like a known issue. I used X509KeyStorageFlags.MachineKeySet | X509KeyStorageFlags.PersistKeySet | X509KeyStorageFlags.Exportable flags together and problem disappeared. Other solution is to change the identity of applicationpool to LOCALSERVICE.
Does throwing an exception in a windows service crash the service?
i.e. it will have to be restarted manually
Note:
I am throwing the exception from within the catch clause.
Not strictly so -- it'd only cause problems if the exception is unhandled.
If the exception is uncaught and bubbles back up to the OnStart() method it will crash the service. You will typically see a message in the Windows Event Log similar to the following:
"The MyServiceName Service service terminated unexpectedly. It has done this x time(s).
If you're throwing the exception in Catch, and there's nothing above it to recatch it, then that will cause your service to stop. The OnStart() method needs a try/catch. If you don't want to stop the service when an Exception occurs, then you need to handle it (log it and move on, or whatever).
My preference woudld be to handle expected exceptions, and to have unexpected exceptions either cause the service to stop, or at least stop/restart automatically. If something unexpected happens your service will be running in an unknown state, and who knows what it will do.
We ran into the problem of an untrapped exception on a child thread causing the service to stop without providing any information about what was causing the exception. We used this method to find out the source of the exception.
You can put a Handler to the service to catch all unhandled exceptions (including all sub threads of the service). In VB.NET, you will need to add a handler for AppDomain.CurrentDomain.UnhandledException. It is likely similar in C#. It will then catch anything that does bubble up past your onStart. You can choose to consume it there or allow it to crash the service from there.