I am trying to see the execution status of a job I ran, but at some random points I get the following error:
2015-10-14T14:41:24-0400 1.2.0.RELEASE ERROR qtp195949131-28 rest.RestControllerAdvice - Caught exception while handling a request
org.springframework.http.converter.HttpMessageNotWritableException: Could not write content: java.lang.Integer cannot be cast to java.lang.String (through reference chain: org.springframework.xd.rest.domain.JobExecutionInfoResource["jobExecution"]->org.springframework.batch.core.JobExecution["executionContext"]->org.springframework.batch.item.ExecutionContext["values"]->java.util.concurrent.EntrySetView[0]->java.util.concurrent.MapEntry["value"]->java.util.ArrayList[0]); nested exception is com.fasterxml.jackson.databind.JsonMappingException: java.lang.Integer cannot be cast to java.lang.String (through reference chain: org.springframework.xd.rest.domain.JobExecutionInfoResource["jobExecution"]->org.springframework.batch.core.JobExecution["executionContext"]->org.springframework.batch.item.ExecutionContext["values"]->java.util.concurrent.EntrySetView[0]->java.util.concurrent.MapEntry["value"]->java.util.ArrayList[0])
Now, I say "random", but the truth is I don't even know which step causes this exception since those are the only logs I have. The jobs run successfully with seemingly no errors, but this really worries me. I've been looking online for days for this, but I don't see anything that can either help me debug this, or even gives an inkling of what might cause this. Any help?
Thanks, N.S.
Okay, so I figured out that the problem was that we were serializing in the execution context a List>, and one of those internal maps contained an Integer as an Object instead of a String. This seems to cause the deserialization of the context to crash.
Solution? Don't store that list within the execution context (instead we wrote the whole list object to a file for transferring between various steps).
Related
In my batch job, I have a single step with reading from Database , processing the record and writing back the same record to same table.(ie updating record with processed values or error reason if processing failed).
I am using AsyncItemProcessor for multi thread processing. When I get error in ItemProcessor.process() method, I throw an exception and batch job ends with FAILED status. This failed status is a requirement.
Because, its AsyncItemProcessor, I am unable to access ItemProcessListener.onProcessError().
How do I write the errorMessage to Item Table when there is an error ?
This is a known limitation of using the AsyncItemProcessor which is mentioned in its Javadoc:
While not an exhaustive list, things like StepExecution.filterCount will not
reflect the number of filtered items and
ItemProcessListener.onProcessError(Object, Exception) will not be called.
There is an open issue to update the reference documentation as well.
How do I write the errorMessage to Item Table when there is an error ?
The AsyncItemProcessor submits a FutureTask to the task executor and the only way to know if an exception happened in the task is by unwrapping the future (the exception will be actually wrapped in a java.util.concurrent.ExecutionException when the FutureTask.get is called). Now since the future is unwrapped in the AsyncItemWriter, you can use an ItemWriteListener and react to processing errors. You can find a complete example here.
After disk space is finish I got InternalError. Adding disk space wasn't fix problem.
Is it possible to restore and continue to persist?
May be on error I can try to recreate/close?
Creation of the queue queue = SingleChronicleQueueBuilder.binary(basePath)
.build();
Writing on a single thread "TradeReactorEventPersister-1"
ExcerptAppender appender = acquireAppender;
if (appender == null) {
appender = queue.acquireAppender();
acquireAppender = appender;
}
appender.writeBytes(BytesStore.wrap(b));
After next exceptions:
2019-08-23 08:13:26.963 +0000 ERROR [TradeReactorEventPersister-1] LoggingUncaughtExceptionHandler - Uncaught exception a fault occurred in a recent unsafe memory access operation in compiled Java code in thread TradeReactorEventPersister-1
java.lang.InternalError: a fault occurred in a recent unsafe memory access operation in compiled Java code
at net.openhft.chronicle.wire.AbstractWire.updateHeaderAssertions(AbstractWire.java:546)
at net.openhft.chronicle.wire.AbstractWire.updateHeader(AbstractWire.java:533)
at net.openhft.chronicle.queue.impl.single.SingleChronicleQueueExcerpts$StoreAppender.writeBytes(SingleChronicleQueueExcerpts.java:470)
2019-08-23 08:13:26.965 +0000 ERROR [TradeReactorEventPersister-1] LoggingUncaughtExceptionHandler - Uncaught exception a fault occurred in a recent unsafe memory access operation in compiled Java code in thread TradeReactorEventPersister-1
java.lang.InternalError: a fault occurred in a recent unsafe memory access operation in compiled Java code
at net.openhft.chronicle.wire.AbstractWire.updateHeaderAssertions(AbstractWire.java:547)
at net.openhft.chronicle.wire.AbstractWire.updateHeader(AbstractWire.java:533)
at net.openhft.chronicle.queue.impl.single.SingleChronicleQueueExcerpts$StoreAppender.writeBytes(SingleChronicleQueueExcerpts.java:470)
2019-08-23 08:13:27.166 +0000 ERROR [TradeReactorEventPersister-1] LoggingUncaughtExceptionHandler - Uncaught exception a fault occurred in a recent unsafe memory access operation in compiled Java code in thread TradeReactorEventPersister-1
java.lang.InternalError: a fault occurred in a recent unsafe memory access operation in compiled Java code
at net.openhft.chronicle.wire.AbstractWire.updateHeader(AbstractWire.java:511)
at net.openhft.chronicle.queue.impl.single.SingleChronicleQueueExcerpts$StoreAppender.writeBytes(SingleChronicleQueueExcerpts.java:470)
2019-08-23 08:13:27.167 +0000 ERROR [TradeReactorEventPersister-1] LoggingUncaughtExceptionHandler - Uncaught exception you cant put a header inside a header, check that you have not nested the documents. If you are using Chronicle-Queue please ensure that you have a unique instance of the Appender per thread, in other-words you can not share appenders across threads. in thread TradeReactorEventPersister-1
java.lang.AssertionError: you cant put a header inside a header, check that you have not nested the documents. If you are using Chronicle-Queue please ensure that you have a unique instance of the Appender per thread, in other-words you can not share appenders across threads.
at net.openhft.chronicle.wire.AbstractWire.enterHeader(AbstractWire.java:322)
at net.openhft.chronicle.queue.impl.single.SingleChronicleQueueExcerpts$StoreAppender.writeHeader(SingleChronicleQueueExcerpts.java:405)
at net.openhft.chronicle.queue.impl.single.SingleChronicleQueueExcerpts$StoreAppender.writeBytes(SingleChronicleQueueExcerpts.java:463)
I couldn't persist after adding disk space.
I got last exception on every trying to persist event:
2019-08-23 08:22:50.746 +0000 ERROR [TradeReactorEventPersister-1] LoggingUncaughtExceptionHandler - Uncaught exception you cant put a header inside a header, check that you have not nested the documents. If you are using Chronicle-Queue please ensure that you have a unique instance of the Appender per thread, in other-words you can not share appenders across threads. in thread TradeReactorEventPersister-1
java.lang.AssertionError: you cant put a header inside a header, check that you have not nested the documents. If you are using Chronicle-Queue please ensure that you have a unique instance of the Appender per thread, in other-words you can not share appenders across threads.
at net.openhft.chronicle.wire.AbstractWire.enterHeader(AbstractWire.java:322)
at net.openhft.chronicle.queue.impl.single.SingleChronicleQueueExcerpts$StoreAppender.writeHeader(SingleChronicleQueueExcerpts.java:405)
at net.openhft.chronicle.queue.impl.single.SingleChronicleQueueExcerpts$StoreAppender.writeBytes(SingleChronicleQueueExcerpts.java:463)
Unfortunately chronicle queue works at the pretty low level, and it is unable to automatically repair itself after data corruption (and disk space will inevitably lead to data corruption). BTW to avoid this, Chronicle Queue will warn you if you are running low on disk space, you should've seen a warning message like:
"your disk " + this.fileStore + " is almost full, warning: chronicle-queue may crash if it runs out of space."
PS you shouldn't really need to do the lazy acquire logic. You can always simply do queue.acquireAppender() - it's a cheap call which gets preexisting appender from the ThreadLocal pool, and will not create the new appender every time.
I am new to using SQL Profiler and have been using it to try and identify the source of an exception. It occurs during a trigger but does not appear to be caused by it. I have the Exception EventClass selected but I do not see any information as to where the exception was thrown from.
The exception occurs after a SELECT in the trigger that works successfully. I have inserted a RAISERROR after the select to log the parameters and return values from the select. They are all valid.
As I put more RAISERROR statements in, the exception moves further down within the trace.
I must be missing something in how to log the Exception in the profiler. I just cannot see where the exception is coming from so I can get to it and fix it.
The text of the exception is "Arithmetic overflow error converting expression to data type datetime."
Found it. Needed more events to properly encapsulate the exception in Profiler.
Can someone tell me what exactly is that about?
I have table and inside the tableCell I have a pickerview and some textfields in other cells.
When i'm scrolling the table up and down 8-10 times app crashes and gives me this error:
* Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '-[UIDeviceRGBColor isEqualToString:]: unrecognized selector sent to instance 0x5834850'
Short answer: it is trying to call -isEqualToString: on an instance of UIDeviceRGBColor, which is doesn't respond to it.
Long answer: you're either asking for the wrong object at some point, or quite possibly trying to access an object that has been released, but who's pointer has not been set to nil. Sometimes when this happens you'll get a straight crash as the memory in the new location isn't a proper object. Sometimes a new object takes its place. The best way to find out is to turn on Zombies.
This is a good overview of how to use Zombies: http://iosdevelopertips.com/debugging/tracking-down-exc_bad_access-errors-with-nszombieenabled.html
You may start seeing messages saying "-[NSCFString isEqualToString:] message sent to deallocated instance". If so then this is a memory management problem and you need to double check your retains & releases. If you don't get this message then you are likely calling the wrong method and so getting the wrong object back.
I am having big problems in fetching exception details from Remote EJBs...
I have a pipeline pattern implemented with Remote EJBs, where one EJB calls other EJBs to do certain tasks. What I can't figure out is how to get more meaningful exceptions when some problem occures.
Here is an example of a "very useful" output I typically get from the EJB container (Glassfish):
2010-11-18 12:22:36,974 DEBUG [CustomerDetectionFilter.java:48 [eef819a4debb613d0670dab35c39] - Checking customer details ...
2010-11-18 12:22:37,026 ERROR [ServiceCore.java:104] [eef819a4debb613d0670dab35c39] - nested exception is: java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
java.rmi.RemoteException: null; nested exception is:
javax.transaction.TransactionRolledbackException: CORBA TRANSACTION_ROLLEDBACK 9998 Maybe; nested exception is:
org.omg.CORBA.TRANSACTION_ROLLEDBACK: vmcid: 0x2000 minor code: 1806 completed: Maybe
javax.ejb.EJBException: nested exception is: java.rmi.ServerException: RemoteException occurred in server thread; nested exception is:
java.rmi.RemoteException: null; nested exception is:
javax.transaction.TransactionRolledbackException: CORBA TRANSACTION_ROLLEDBACK 9998 Maybe; nested exception is:
org.omg.CORBA.TRANSACTION_ROLLEDBACK: vmcid: 0x2000 minor code: 1806 completed: Maybe
at com.my.remote._CustomerDetectionFilterRemote_Wrapper.execute(com/my/remote/_CustomerDetectionFilterRemote_Wrapper.java) ~[project-common.jar:na]
So in this case I would know that this is the cause:
java.rmi.RemoteException: null
... but I have no way of getting more useful information for debugging.
Can you recommend a way of excepting handling where the caller of remote EJB needs to get more details about the problem that occured? AppServer is Glassfish 2.1.
Thank you,
Bozo
There are various ways for handling exceptions. We can configure them to get most information about root cause from it.
Below link might provide useful information & topic is discussed briefly.
Best practices in EJB exception handling - http://www.ibm.com/developerworks/java/library/j-ejbexcept.html