Okhttp error during React Navtive GET request - react-native

Receiving this error during an otherwise valid GET request in a react-native project.
2020-08-11 12:12:54.163 7301-7498/com.cigna.mobile.mycigna.debug E/AndroidRuntime: FATAL EXCEPTION: OkHttp Dispatcher
Process: com.cigna.mobile.mycigna.debug, PID: 7301
java.lang.NoSuchMethodError: No static method delimiterOffset(Ljava/lang/String;IILjava/lang/String;)I in class Lokhttp3/internal/Util; or its super classes (declaration of 'okhttp3.internal.Util' appears in /data/app/~~-wSG5UWGWR49_zqj0uGdfw==/com.cigna.mobile.mycigna.debug-O6Kl4LYWC-jBUFRzAxGZug==/base.apk!classes6.dex)
at okhttp3.JavaNetCookieJar.decodeHeaderAsJavaNetCookies(JavaNetCookieJar.java:91)
at okhttp3.JavaNetCookieJar.loadForRequest(JavaNetCookieJar.java:74)
at com.facebook.react.modules.network.ReactCookieJarContainer.loadForRequest(ReactCookieJarContainer.java:44)
at okhttp3.internal.http.BridgeInterceptor.intercept(BridgeInterceptor.kt:75)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:112)
at okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.kt:71)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:112)
at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:87)
at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.kt:184)
at okhttp3.RealCall$AsyncCall.run(RealCall.kt:136)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
at java.lang.Thread.run(Thread.java:923)
2020-08-11 12:12:54.552 631-716/system_process E/InputDispatcher: channel '94b38db com.cigna.mobile.mycigna.debug/com.cigna.mycigna.ui.dashboard.HomeActivity (server)' ~ Channel is unrecoverably broken and will be disposed!
All other api requests on my application work without problem. As well, the request mentioned works seemlessly on iOS.

You've got two libraries: okhttp and okhttp-urlconnection. They must be on the same exact version or you may receive this error.

Related

ReactNative app crashes FATAL EXCEPTION: OkHttp Dispatcher

I am making a request to the api with axios and after getting the results, the app crashes. I mention that the request returns only json text.
The request finishes successfully, promise returns success, only thing is that the app crashes without debug logs, only the provided logcat log.
Process: host.exp.exponent, PID: 23720
java.lang.OutOfMemoryError: Failed to allocate a 25090000 byte allocation with 6291456 free bytes and 18MB until OOM, max allowed footprint 390069440, growth limit 402653184
at java.lang.StringBuilder.toString(StringBuilder.java:410)
at android.util.JsonReader.nextString(JsonReader.java:894)
at android.util.JsonReader.nextValue(JsonReader.java:708)
at android.util.JsonReader.objectValue(JsonReader.java:691)
at android.util.JsonReader.peek(JsonReader.java:347)
at abi31_0_0.com.facebook.react.devsupport.JSDebuggerWebSocketClient.onMessage(JSDebuggerWebSocketClient.java:187)
at expolib_v1.a.a.i.a.b(RealWebSocket.java:307)
at expolib_v1.a.a.i.c.e(WebSocketReader.java:222)
at expolib_v1.a.a.i.c.a(WebSocketReader.java:101)
at expolib_v1.a.a.i.a.b(RealWebSocket.java:262)
at expolib_v1.a.a.i.a$2.onResponse(RealWebSocket.java:201)
at expolib_v1.a.y$a.c(RealCall.java:135)
at expolib_v1.a.a.b.run(NamedRunnable.java:32)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636)
at java.lang.Thread.run(Thread.java:764)
I expected it to work... instead, I get this error message.

okhttp 3.7.0 SSL Shutdown failed threw UnknownHostException and not SSLException

While making a network request with low connectivity very rarely I see that I get
<-- HTTP FAILED: java.net.UnknownHostException: Unable to resolve host ....
while my server seems to have got the request correctly. I found 1 instance of it with device logs which shows actually an SSLException happened
D/NativeCrypto: jniThrowException: javax/net/ssl/SSLException: Read error: ssl=0x7dc365f080: I/O error during system call, Software caused connection abort
D/NativeCrypto: jniThrowException: javax/net/ssl/SSLException: SSL shutdown failed: ssl=0x7dc365f080: I/O error during system call, Broken pipe
My question is why does okhttp and retrofit throw UnknownHostException and not SSLException, and is there a way to actually get the SSLException as currently my app thinks the request did not go while server processes that request.
I am using
okhttp:3.10.0
retrofit:2.2.0
adapter-rxjava2:2.2.0

HTTPS request causes Uncaught exception Caller Tenant ID cannot be -1

WSO2 REST proxy service called via HTTP has no problems, but calling via HTTPS sometimes throws exception:
TID: [0] [ESB] [2016-06-15 16:52:59,693] ERROR {org.apache.axis2.transport.base.threads.NativeWorkerPool} - Uncaught exception {org.apache.axis2.transport.base.threads.NativeWorkerPool}
java.lang.IllegalStateException: Caller Tenant ID cannot be -1
at org.wso2.carbon.caching.impl.Util.checkAccess(Util.java:36) org.wso2.carbon.caching.impl.CarbonCacheManager.getCache(CarbonCacheManager.java:111)
org.wso2.carbon.security.pox.POXSecurityHandler.getPOXCache(POXSecurityHandler.java:414)at org.wso2.carbon.security.pox.POXSecurityHandler.invoke(POXSecurityHandler.java:153)
Proxy uses the iterator and aggregate mediators.
This is a known issue. It has been fixed but as of now, there hasn't been a release since the fix.
Therefore you can get a clone of the repo with latest changes and build it manually to solve the issue.

JBoss AS7 Hornetq - RemoteConenctionFactory lookup fails with RoundRobinConnectionLoadBalancingPolicy NotSerializableException

I'm using JBoss AS 7 Hornetq. Our standalone java application interacts with a queue and sends messages. We had the entire environment setup and it was working pretty smoothly. Suddenly, one fine day, our standalone application failed with the below exception:
Caused by: java.io.NotSerializableException: org.hornetq.api.core.client.loadbalance.RoundRobinConnectionLoadBalancingPolicy
Detailed exception stack trace is below
javax.naming.NamingException: Failed to lookup [Root exception is java.io.NotSerializableException: org.hornetq.api.core.client.loadbalance.RoundRobinConnectionLoadBalancingPolicy]
at org.jboss.naming.remote.client.ClientUtil.namingException(ClientUtil.java:36)
at org.jboss.naming.remote.protocol.v1.Protocol$1.execute(Protocol.java:104)
at org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1.lookup(RemoteNamingStoreV1.java:79)
at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:79)
at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:83)
at javax.naming.InitialContext.lookup(Unknown Source)
at com.infosys.lbs.publishing.LocationProcessor.postMessageInQueue(LocationProcessor.java:377)
at com.infosys.lbs.publishing.LocationProcessor.process(LocationProcessor.java:69)
at com.infosys.lbs.publishing.main.Publisher.main(Publisher.java:34)
Caused by: java.io.NotSerializableException: org.hornetq.api.core.client.loadbalance.RoundRobinConnectionLoadBalancingPolicy
at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:891)
at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:998)
at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62)
at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119)
at org.jboss.naming.remote.protocol.v1.Protocol$1$2.write(Protocol.java:138)
at org.jboss.naming.remote.protocol.v1.WriteUtil.write(WriteUtil.java:61)
at org.jboss.naming.remote.protocol.v1.Protocol$1.handleServerMessage(Protocol.java:128)
at org.jboss.naming.remote.protocol.v1.RemoteNamingServerV1$MessageReciever$1.run(RemoteNamingServerV1.java:73)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: an exception which occurred:
in field loadBalancingPolicy
in field serverLocator
in object org.hornetq.jms.client.HornetQJMSConnectionFactory#ea074d
Exception was happening when the app was trying to lookup the connection factory
QueueConnectionFactory qcf = (QueueConnectionFactory)context.lookup("jms/RemoteConnectionFactory");
Below are the steps on how we resolved the issue
There was almost zero help for resolving this issue. A web search on this exception returned next to nothing. However, this particular thread on JBoss AS Dev site spinned a thought in my head: RemoteConnectionFactory is not found when looking up in a remote client
The scenario mentioned in this thread was not same as ours. (In our app this is the first and the only lookup happening.) This thread got me thinking towards a possible connection factory initialization issue. While there is nothing I could do to debug or find the issue around it, I thought that if I could reinitialize it, that would help.
So I tried lookup with java:jboss/exported/jms/RemoteConnectionFactory As expected it failed with a NamingException. Hoping that this naming syntax (using java:/) would have resulted in a reinitialization, I tried lookup again with jms/RemoteConnectionFactory. And bingo!!! it worked!
Unfortunately, we still don't know why it happened, and if it is just a one-off case! Documenting it here just in case some mortal soul hits this issue.

Glassfish Bean Validation weird error

I am using bean validation in my application. When there is no constraint validation errors everything works nicely. Every time there is a validation error, Glassfish throws the following exception:
Caused by: java.lang.ClassNotFoundException: javax.validation.groups.Default: java.net.MalformedURLException: Unknown protocol: osgi
at com.sun.corba.ee.impl.util.JDKBridge.loadClassM(JDKBridge.java:325)
at com.sun.corba.ee.impl.util.JDKBridge.loadClass(JDKBridge.java:228)
at com.sun.corba.ee.impl.javax.rmi.CORBA.Util.loadClass(Util.java:640)
at com.sun.corba.ee.impl.util.RepositoryId.getClassFromType(RepositoryId.java:628)
at com.sun.corba.ee.impl.orbutil.RepIdDelegator.getClassFromType(RepIdDelegator.java:169)
at com.sun.corba.ee.impl.encoding.CDRInputStream_1_0.readClass(CDRInputStream_1_0.java:1439)
The bean-validation.jar is present in glassfish/modules folder. The startup doesn't throw any exceptions regarding validation.
PS. Note that we are using remote beans with CORBA.
Reproducable on GlassFish 3.1.2.2 and 3.1.1.
I traced this problem to serialization of the ConstraintValidationException through CORBA. Somehow the bean-validation module is not loaded properly with osgi and the javax.validation.groups.Default class is missing. I made a quick workaround so that the ConstraintValidationException is intercepted and never sent through CORBA. Instead the validation error information is gathered in a custom Exception class that can be actually serialized through the services.