I have a JRuby/Rails application comprising a web server to process HTTP requests, a MySQL database, and a Resque worker to process enqueued jobs. When I'm in development mode and something in the web application throws an exception, I get a nice trace in the browser, showing the exception thrown, the line at which it was thrown, relevant data, and a stack traceback.
However, when exception-throwing code executes in a Resque worker, I get nothing, even if I know that the code has thrown an exception. The only way that I can debug is to throw in print statements and figure out where the last print statement was called before the Resque worker threw the exception and crashed.
Is there a way to get the Resque worker to spit out an exception log and stack traceback into the log file (before it crashes), so that I can see what happened?
EDIT - (Thanks for the idea #Viren) - And I don't want to litter my application code with begin/rescue blocks. I'll put the begin/rescue code in once somewhere to make sure that the exception traceback gets logged, but I don't know where to put it.
You can set your Resque logger to use the Rails logger. For full stack trace you might want to set it to DEBUG level, which prints out lots of information. You put it in initializers/resque.rb:
Resque.logger = Rails.logger
Resque.logger.level = Logger::DEBUG
There also resque-backtrace gem, although it has this drawback that it overwrites the backend in Resque so now no jobs will ever make it to the error queue.
Related
In my web application, I have a custom configuration file which I want to monitor for changes and update the application settings immediately. So I am using IOptionsMonitor<T> to get this done. It works well.
As per the documentation the method that gets called when configuration file changed is wired up like below.
var data = _serviceProvider.GetRequiredService<IOptionsMonitor<MySettings>>();
data.OnChange(OnReaderSettingOptionsChanged);
Within the OnReaderSettingOptionsChanged() method, I do some validations and there is a need to throw an exception on an edge case so that application shouldn't continue.
The problem is when I throw the exception, I expect to see a error on browser (dev mode with details or normal error otherwise). But it's not showing because according to this exception gets fired in another thread.
So, is there another way for me to get this across to browser?
I have an application instance, backed by a web service using OIM Webservices Connector.
This connector is used in a synchronous manner by OIM, so when I create a new account in OIM for this application instance, the webservice calls the partner link's method.
Until the method ends its execution, the OIM screen hangs (as expected).
What seems strange to me is that, no matter the partner link's method executes successfully or not (when it does not execute properly, it throws an exception), the OIM operation actually ignores the exception and completes the operation.
Even if I explicitly throw an exception in the BPEL, I can see the error in the webservice log in weblogic, but the OIM method completes anyway.
What one would expect from a situation like this, I guess, is that OIM could just give an error message on the screen, because the operation failed. But no, OIM ignores the errors and go on.
Then I've tried to change the process definition in Design Console to force the process to stop on any error, setting the flag "required for completion" below
So I think I am missing something here
How can I make OIM abort some operation when the webservice connector throws an exception?
Assuming you're throwing a ConnectorException, check in the 'Responses' tab that you have that exception mapped, and in the 'Task to Object Status Mapping' you're setting the desired target Object Status for the object status setted before.
I have a Rails 3 app that is using the exception_notification gem to send emails about exceptions.
I would also like to show users specific error messages when exceptions occur, but by catching a generic Exception because I'm not sure of all the exceptions that can occur. I'm thinking the way to do this is to rescue from Exception, and then raise a custom exception. That way I'm still getting an email about the exception, and the user can see the custom exception's error page.
Does this sound like a Rails 3 way to do things?
Thanks a lot.
I think not.
As Ryan Davis says
Don’t rescue Exception. EVER. Or I will stab you.
More info about that statement here.
Rails 3.2 does exception handling in two middlewares:
ActionDispatch::ShowExceptions
ActionDispatch::DebugExceptions
You can check that one by running
$ rake middleware
ActionDispatch::ShowExceptions [source]
Used in production to render the exception pages.
ActionDispatch::DebugExceptions [source]
Used in development environment to render detailed stack traces when exceptions occur. Stops the middleware call chain and renders the stack trace if action_dispatch.show_detailed_exceptions is true to be more precise.
So the most simple way of doing something normal with this middleware would be monkeypatching the call method of ActionDispatch::DebugExceptions, doing all you need to do and then calling the original method.
The better way of doing this is, however, including your own middleware between those two. In it, you would wrap the call inside a rescue block and do your custom processing.
I am a maintainer of Airbrake and this is exactly what we're doing right now.
You might also want to check Errbit, the self-hosted alternative.
I have a .Net Compact Framework 3.5 application that uses Nlog version 2.0 to log Info, Error and Fatal Exceptions. Most of the time the logging works as expected and logs fatal exceptions before crashing. But at times it is observed that application crashes without leaving any signs of an error/exception.
Let me elaborate the scenario:
The Application creates few threads, all the threads have try-catch block added at the beginning of their call stacks. And hence log fetal
exceptions before crashing.
The main thread have 'AppDomain.CurrentDomain.UnhandledException' to log any fetal exceptions on its call stack.
The application does load some third party managed dlls and performs some PInvokes on Wnce dlls.
But I believe even if some third party DLL crashes (or let’s say it creates a new thread which crashes), I should at least see some ThreadAbortExceptions in the log, logged by my application's thread before exiting.
The key configuration parameters of Nlog are:
a. FileTarget.AutoFlush = true
b. FileTarget.KeepFileOpen= false
c. FileTarget is not wrapped in any async wrapper or in any buffered
wrapper.
Please let me know if I'm missing anything.
Possible reasons for the crash include OutOfMemory exception or StackOverflowException. From the documentation for the latter:
Version Considerations
In prior versions of the .NET Framework, your application could catch a StackOverflowException object (for example, to recover from unbounded recursion). However, that practice is currently discouraged because significant additional code is required to reliably catch a stack overflow exception and continue program execution.
Starting with the .NET Framework version 2.0, a StackOverflowException object cannot be caught by a try-catch block and the corresponding process is terminated by default. Consequently, users are advised to write their code to detect and prevent a stack overflow. For example, if your application depends on recursion, use a counter or a state condition to terminate the recursive loop. Note that an application that hosts the common language runtime (CLR) can specify that the CLR unload the application domain where the stack overflow exception occurs and let the corresponding process continue. For more information, see ICLRPolicyManager Interface and Hosting Overview.
I'm running two glassfish v2 domains containing stateless session EJBs. In a few cases, an EJB in one domain has to call one in the other.
My problem is that when the called EJB aborts with an exception, the caller does not receive the message of the exception and instead reports an internal error that is not helpful at all in diagnosing the problem. What happens seems to be this:
At the transport layer, a org.omg.CORBA.portable.ApplicationException is created,which already loses all detail information about the exception except its class.
Inside com.sun.jts.CosTransactions.TopCoordinator.get_txcontext(), the status of the transaction ass rolled back causes a org.omg.CosTransactions.Unavailable to be thrown, which gets wrapped and passed around a few times and eventually results into this error being displayed to the user:
org.omg.CORBA.INVALID_TRANSACTION: vmcid: 0x0 minor code: 0 completed: No
at com.sun.jts.CosTransactions.CurrentTransaction.sendingRequest(CurrentTransaction.java:807)
at com.sun.jts.CosTransactions.SenderReceiver.sending_request(SenderReceiver.java:139)
at com.sun.jts.pi.InterceptorImpl.send_request(InterceptorImpl.java:344)
at com.sun.corba.ee.impl.interceptors.InterceptorInvoker.invokeClientInterceptorStartingPoint(InterceptorInvoker.java:271)
at com.sun.corba.ee.impl.interceptors.PIHandlerImpl.invokeClientPIStartingPoint(PIHandlerImpl.java:348)
at com.sun.corba.ee.impl.protocol.CorbaClientRequestDispatcherImpl.beginRequest(CorbaClientRequestDispatcherImpl.java:284)
at com.sun.corba.ee.impl.protocol.CorbaClientDelegateImpl.request(CorbaClientDelegateImpl.java:184)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:186)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:152)
at com.sun.corba.ee.impl.presentation.rmi.bcel.BCELStubBase.invoke(BCELStubBase.java:225)
Is there anything I can do here to preserve information about the actual cause of the problem?
The cause of the problem should be available in the server log of the domains hosting the EJB that had a problem.
It sounds like getting more info back from the other end may be difficult... I do not know which issue tracker would be the right one for the info lost when the ApplicationException is created/thrown.
A total hack would be to create a set of custom exception classes in the project that has the ejb that has failed. You would make them very fine grained to cover the likely causes of the problem and provide enough detail in their name to identify the actual location of the problem, too. Yucky... but that may be the only choice until an issue gets filed and the fix is distributed.
Is there anything I can do here to
preserve information about the actual
cause of the problem?
Unfortunately, no. The ORB does not use normal object serialization for system exceptions (i.e., org.omg.CORBA.*), which means that causes are lost. As #vkraemer said, you'll need to rely on server logs.
I finally got to the bottom of this: actually, Glassfish transmits exceptions through IIOP quite correctly and everything works as it should... unless you do something idiotic like this:
try{
ejb.getFoo();
}catch (Exception e){
// try again
ejb.getFoo();
}
Yeah, it was our own damn code that swallowed the exception and tried to call a transaction-requiring EJB method within a distributed transaction that's been rolled back due to the exception.