We Keep Coding

camel : stackoverflow error when route is called recursively

I have a camel route which calls itself until a certain condition is met. Basically the idea is to implement the retry of route. When the application is deployed I am getting stackoverflow error when retries happen for a long period.
[Camel (camel-1) thread #1 - Multicast] ERROR com.application.RouteName.lambda$configure$0 - Exception occurred during execution on the exchange: Exchange[ID-batchrater-310822922-1-383133832-34058-1530798326741-0-6]
org.apache.camel.CamelExecutionException: Exception occurred during execution on the exchange: Exchange[ID-batchrater-310822922-1-383133832-34058-1530798326741-0-6]
at org.apache.camel.util.ObjectHelper.wrapCamelExecutionException(ObjectHelper.java:1779)
at org.apache.camel.impl.DefaultExchange.setException(DefaultExchange.java:351)
.
.
.
.
Caused by: java.lang.StackOverflowError: null
at org.springframework.beans.factory.support.AbstractBeanFactory.transformedBeanName(AbstractBeanFactory.java:1117)
at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:239)
at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202)
at org.springframework.context.support.AbstractApplicationContext.getBean(AbstractApplicationContext.java:1084)
at org.apache.camel.spring.spi.ApplicationContextRegistry.lookupByNameAndType(ApplicationContextRegistry.java:47)
at org.apache.camel.impl.PropertyPlaceholderDelegateRegistry.lookupByNameAndType(PropertyPlaceholderDelegateRegistry.java:63)
at org.apache.camel.component.bean.BeanInfo.createParameterMappingStrategy(BeanInfo.java:177)
at org.apache.camel.component.bean.BeanInfo.<init>(BeanInfo.java:99)
I believe the stackoverflow error is due to the recursive call of route and I changed the route structure and now redelivery is handled by the retryDelivery mechanisms available in camel onException() . And my number of retries can be infinite until the condition is met.
I need to know will there be any chance of stackOverFlow again with this approach.

No this is the right approach to handle error handling redeliveries with the onException and other error handling features. Using the loop EIP leads to longer stack-frames and should not be used for looping very long. So you did the right fix.

Jackson parse exception while using Guava's RateLimiter

I am using Guava's RateLimiter so I don't hit the max requests per second (I'ts 5..) at the API. It works fine, I never hit the rate limit now but I have a strange problem now. For some reason it gives 1 out of 5 times running the app an exception for one of the 6 calls:
java.lang.NullPointerException: Attempt to invoke virtual method 'boolean com.fasterxml.jackson.databind.JavaType.equals(java.lang.Object)' on a null object reference
at com.fasterxml.jackson.databind.type.ResolvedRecursiveType.equals(ResolvedRecursiveType.java:103)
at com.fasterxml.jackson.databind.type.TypeBindings$AsKey.equals(TypeBindings.java:458)
at java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1014)
at java.util.concurrent.ConcurrentHashMap.putIfAbsent(ConcurrentHashMap.java:1522)
at com.fasterxml.jackson.databind.util.LRUMap.putIfAbsent(LRUMap.java:64)
at com.fasterxml.jackson.databind.type.TypeFactory._fromClass(TypeFactory.java:1274)
at com.fasterxml.jackson.databind.type.TypeFactory._fromParamType(TypeFactory.java:1384)
at com.fasterxml.jackson.databind.type.TypeFactory._fromAny(TypeFactory.java:1154)
at com.fasterxml.jackson.databind.type.TypeFactory._resolveSuperInterfaces(TypeFactory.java:1298)
at com.fasterxml.jackson.databind.type.TypeFactory._fromClass(TypeFactory.java:1247)
at com.fasterxml.jackson.databind.type.TypeFactory._fromAny(TypeFactory.java:1150)
at com.fasterxml.jackson.databind.type.TypeFactory.constructType(TypeFactory.java:618)
at com.fasterxml.jackson.databind.cfg.MapperConfig.constructType(MapperConfig.java:290)
at com.fasterxml.jackson.databind.cfg.MapperConfig.introspectClassAnnotations(MapperConfig.java:320)
at com.fasterxml.jackson.databind.deser.BasicDeserializerFactory.findTypeDeserializer(BasicDeserializerFactory.java:1338)
at com.fasterxml.jackson.databind.DeserializationContext.findRootValueDeserializer(DeserializationContext.java:481)
at com.fasterxml.jackson.databind.ObjectMapper._findRootDeserializer(ObjectMapper.java:3890)
at com.fasterxml.jackson.databind.ObjectMapper._readValue(ObjectMapper.java:3756)
at com.fasterxml.jackson.databind.ObjectMapper.readTree(ObjectMapper.java:2198)
at dk.nykredit.jackson.dataformat.hal.deser.HALBeanDeserializer.deserialize(HALBeanDeserializer.java:27)
at com.fasterxml.jackson.databind.ObjectMapper._readMapAndClose(ObjectMapper.java:3789)
at com.fasterxml.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:2913)
at org.springframework.http.converter.json.MappingJackson2HttpMessageConverter.readJavaType(MappingJackson2HttpMessageConverter.java:179)
at org.springframework.http.converter.json.MappingJackson2HttpMessageConverter.read(MappingJackson2HttpMessageConverter.java:174)
at org.springframework.web.client.HttpMessageConverterExtractor.extractData(HttpMessageConverterExtractor.java:89)
at org.springframework.web.client.RestTemplate$ResponseEntityResponseExtractor.extractData(RestTemplate.java:738)
at org.springframework.web.client.RestTemplate$ResponseEntityResponseExtractor.extractData(RestTemplate.java:723)
at org.springframework.web.client.RestTemplate.doExecute(RestTemplate.java:544)
at org.springframework.web.client.RestTemplate.execute(RestTemplate.java:506)
at org.springframework.web.client.RestTemplate.exchange(RestTemplate.java:455)
at nl.app.App.API.RestClient_.getAdviseurs(RestClient_.java:117)
at nl.app.App.Services.AdviseurService.getAdviseur(AdviseurService.java:60)
at nl.app.App.Services.AdviseurService.getAdviseurAsync(AdviseurService.java:49)
at nl.app.App.Services.AdviseurService_.access$101(AdviseurService_.java:19)
at nl.app.App.Services.AdviseurService_$2.execute(AdviseurService_.java:66)
at org.androidannotations.api.BackgroundExecutor$Task.run(BackgroundExecutor.java:405)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:428)
at java.util.concurrent.FutureTask.run(FutureTask.java:237)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:272)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1133)

That exception does not appear to have anything to do with RateLimiter. The stack trace is saying that Spring and/or Jackson tried to call .equals() via reflection on a null reference. My guess would be you're passing null to something you shouldn't be - perhaps you're returning null if the rate limiter doesn't have enough permits?
Without seeing the code in question it's hard to say exactly what's causing this error. Try making an MCVE that replicates the error - it's likely simply creating the MCVE will be enough for you to find the issue.

When Hystrix short-circuits and the circuit is OPEN it never closes even after the the offending service is back up

I am having an Issue where when the hystrix circuit breaker trips, it does not close ever again. I have turned logging to debug and I do not see it trying to allow a test request through in which case it seems to me It will never close since its only supposed to close when a test execution goes through successfully indicating that the offending service is now healthy. According to the documentation the Circuit break configuration defaults should be working but I can not seem to tell why the test request is never allowed through.
2016-02-18 09:00:38,782 noodle-soup-service application-akka.actor.default-dispatcher-7 ERROR akka.actor.OneForOneStrategy - CallServiceCommand short-circuited and fallback failed.
com.netflix.hystrix.exception.HystrixRuntimeException: CallServiceCommand short-circuited and fallback failed.
at com.netflix.hystrix.AbstractCommand$16.call(AbstractCommand.java:816) ~[com.netflix.hystrix.hystrix-core-1.4.23.jar:1.4.23]
at com.netflix.hystrix.AbstractCommand$16.call(AbstractCommand.java:790) ~[com.netflix.hystrix.hystrix-core-1.4.23.jar:1.4.23]
at rx.internal.operators.OperatorOnErrorResumeNextViaFunction$1.onError(OperatorOnErrorResumeNextViaFunction.java:99) ~[io.reactivex.rxjava-1.1.0.jar:1.1.0]
at rx.internal.operators.OperatorDoOnEach$1.onError(OperatorDoOnEach.java:71) ~[io.reactivex.rxjava-1.1.0.jar:1.1.0]
...
Caused by: java.lang.RuntimeException: Hystrix circuit short-circuited and is OPEN
at com.netflix.hystrix.AbstractCommand$1.call(AbstractCommand.java:414) ~[com.netflix.hystrix.hystrix-core-1.4.23.jar:1.4.23]
... 38 common frames omitted

In the Akka error handling strategy, I needed to schedule a new test call so that eventually when it succeeds, then Hystrix can close the Circuit.

Android error randomly java.lang.NoClassDefFoundError: com.facebook.internal.Utility

I am using latest Facebook Android SDK and getting that error from dozens of users in my remote crash control app in my latest released apk. I have looked here for such error, but most of the answers are too outdated for last FB SDK, and in this case there are two weird circumstances:
a) The error seems to happen randomly. I have been unable to reproduce it at all on none of my devices.
b) There were no changes in FB logic at all between that release and the previous one, and in the previous release I have never had such error.
Since I couldn't find any relevant difference in the code between such versions, I thought the problem was something wrong could have happened with Android Tools while generating the last apk, but giving the fact that very same apk is the one I am using and have been unable to reproduce the problem and, despite dozens or users are affected, hundreds using the same apk aren't, I discarded also such hypothesis.
Any ideas on how to solve or just debug this thing are welcome.
More info that could be relevant:
All crashes happened in Android 4.0.3 or older. The highest percentage is for 2.3.6 with 48% of all the crashes.
That class is actually exported in the APK. I have checked it by unzipping the apk and using dexdump to see what is inside classes.dex. I couldn't expected other thing, since it works perfectly in all my devices and if the class weren't there, it would not.
$ ~/android-sdks/build-tools/21.1.1/dexdump classes.dex | grep 'com.facebook.internal.Utility$1'
Class descriptor : 'Lcom/facebook/internal/Utility$1;'
#0 : (in Lcom/facebook/internal/Utility$1;)
#1 : (in Lcom/facebook/internal/Utility$1;)
#2 : (in Lcom/facebook/internal/Utility$1;)
#0 : (in Lcom/facebook/internal/Utility$1;)
#0 : (in Lcom/facebook/internal/Utility$1;)
#1 : (in Lcom/facebook/internal/Utility$1;)
#2 : (in Lcom/facebook/internal/Utility$1;)
#3 : (in Lcom/facebook/internal/Utility$1;)
It seems to fail after an invocation of a Utility's static method from loadAppSettingsAsync, that happens to be a static method within the same class. So, if the com.facebook.internal.Utility class does not exist or couldn't be loaded, how it is possible that com.facebook.internal.Utility.loadAppSettingsAsync is executed in first place? and if it exists and it is loaded, why is NoClassDefFoundError thrown on com.facebook.internal.Utility? I am so f* lost...
Here the stack from splunk mint (formerly known as bugsense), I just changed the name of the app. I retraced it with the proguard map file, but it seems it missed some line numbers anyway:
java.lang.NoClassDefFoundError: com.facebook.internal.Utility$1
at com.facebook.internal.Utility.void loadAppSettingsAsync(android.content.Context,java.lang.String)(Unknown Source)
at com.facebook.Settings.void sdkInitialize(android.content.Context)(Unknown Source)
at com.facebook.UiLifecycleHelper.<init>(Unknown Source)
at net.iberdroid.androidgames.framework.impl.AndroidGame.void onCreate(android.os.Bundle)(Unknown Source)
at com.marzoa.ruletafree.xmas2012.RuletaAfortunadaGame.void onCreate(android.os.Bundle)(Unknown Source)
at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1050)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1623)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:1675)
at android.app.ActivityThread.access$1500(ActivityThread.java:121)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:943)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:130)
at android.app.ActivityThread.main(ActivityThread.java:3770)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:507)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:912)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:670)
at dalvik.system.NativeStart.main(Native Method)
Caused by: java.lang.ClassNotFoundException: com.facebook.internal.Utility$1 in loader dalvik.system.PathClassLoader[/data/app/com.marzoa.ruletafree.xmas2012-2.apk]
at dalvik.system.PathClassLoader.findClass(PathClassLoader.java:240)
at java.lang.ClassLoader.loadClass(ClassLoader.java:551)
at java.lang.ClassLoader.loadClass(ClassLoader.java:511)
... 18 more

As the NoClassDefFoundError occurs in loadAppSettingsAsync at an anonymous implementation of AsyncTask it seems to be the same problem like this NoClassDefFoundError - Android 2.3.X
Its a bug in google play services. (https://code.google.com/p/android/issues/detail?id=81083)
Try to add following into your Application#onCreate() method as described in the answer of the referred issue.
try {
Class.forName("android.os.AsyncTask");
}
catch(Throwable ignore) {
// ignored
}

Firstly, be sure that you are checking for the right class. According to the error message, the "missing" class is com.facebook.internal.loadAppSettingsAsync$1. Note the $1!! That means we are talking about an anonymous inner class that is declared within the Utility.loadAppSettingsAsync.
Second, java.lang.NoClassDefFoundError can have a number of causes:
The class may be missing.
The class could be present but unloadable for some reason.
The class could be loadable, but a previous attempt to initialize it ... or some dependent class ... has failed.
The last case typically happens if a static initialization or static initializer block throws an unchecked exception the first time it was run. (You will typically a log message for this exception.) Once the class initialization has failed once, the class is marked as broken. This stops the class and any other classes that depends on it from being initialized.

Netty 4 leak exception at HttpObjectAggregator

I'm getting an exception on my netty server while it's under heavy load. (Testing with LOIC etc...) I want to know that I do something wrong or it's a bug in the HttpObjectAggregator.
WARNING: LEAK: ByteBuf was GC'd before being released correctly. The following stack trace shows where the leaked object was created, rather than where you failed to release it.
io.netty.util.ResourceLeakException: io.netty.buffer.CompositeByteBuf#1c0eeb6
at io.netty.util.ResourceLeakDetector$DefaultResourceLeak.<init>(ResourceLeakDetector.java:174)
at io.netty.util.ResourceLeakDetector.open(ResourceLeakDetector.java:116)
at io.netty.buffer.CompositeByteBuf.<init>(CompositeByteBuf.java:60)
at io.netty.buffer.Unpooled.compositeBuffer(Unpooled.java:353)
at io.netty.handler.codec.http.HttpObjectAggregator.decode(HttpObjectAggregator.java:138)
at io.netty.handler.codec.http.HttpObjectAggregator.decode(HttpObjectAggregator.java:50)
at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:89)
at io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:334)
at io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:320)
at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:173)
at io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:334)
at io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:320)
at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:785)
at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:100)
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:497)
at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:465)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:359)
at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:101)
at java.lang.Thread.run(Thread.java:722)

Most likely you forgot to release the message after handling it. Did you call release() on it ?