onError occasionally not called - rx-java2

I have an issue with one of my onError handlers occasionally not being called, leaving my application in a kind of lingering state.
This is my code
tokenSubscription = Observable.interval(pluginProperties.getRefreshTokenInterval(), TimeUnit.MILLISECONDS, Schedulers.io())
.subscribe(x -> {
ConversationContextV3 contextV3 = (ConversationContextV3) authenticationContext.getConversationContext();
refreshAccessToken(contextV3);
},
error -> {
logger.error("Exception after retrying refreshing session token, will attempt to reconnect");
disconnect();
}
);
When refreshAccessToken() is called it sometimes throws an exception, which is then handled in onError. Below is the expected output. Notice the last to lines.
2017-09-04 20:11:27.750 [RxCachedThreadScheduler-82] DEBUG c.danlind.igz.brokerapi.BrokerLogin - Refreshing access token
2017-09-04 20:11:27.798 [RxCachedThreadScheduler-82] ERROR c.danlind.igz.adapter.RestApiAdapter - Exception when refreshing session token
org.springframework.web.client.HttpServerErrorException: 503 Service Unavailable
at org.springframework.web.client.DefaultResponseErrorHandler.handleError(DefaultResponseErrorHandler.java:94)
at org.springframework.web.client.RestTemplate.handleResponse(RestTemplate.java:700)
at org.springframework.web.client.RestTemplate.doExecute(RestTemplate.java:653)
at org.springframework.web.client.RestTemplate.execute(RestTemplate.java:613)
at org.springframework.web.client.RestTemplate.exchange(RestTemplate.java:531)
at com.danlind.igz.ig.api.client.RestAPI.refreshSessionV1(RestAPI.java:778)
at com.danlind.igz.adapter.RestApiAdapter.refreshSessionV1(RestApiAdapter.java:281)
at com.danlind.igz.brokerapi.BrokerLogin.refreshAccessToken(BrokerLogin.java:80)
at com.danlind.igz.brokerapi.BrokerLogin.lambda$startRefreshAccessTokenScheduler$17(BrokerLogin.java:99)
... (removed some lines for brevity)
2017-09-04 20:11:27.811 [RxCachedThreadScheduler-82] ERROR c.danlind.igz.brokerapi.BrokerLogin - Exception after retrying refreshing session token, disconnecting
2017-09-04 20:11:27.811 [RxCachedThreadScheduler-82] INFO c.danlind.igz.brokerapi.BrokerLogin - Disconnecting from IG
My issue is that sometimes it seems like onError is never called, leaving me with a log output like this:
2017-09-04 20:11:27.750 [RxCachedThreadScheduler-82] DEBUG c.danlind.igz.brokerapi.BrokerLogin - Refreshing access token
2017-09-04 20:11:27.798 [RxCachedThreadScheduler-82] ERROR c.danlind.igz.adapter.RestApiAdapter - Exception when refreshing session token
org.springframework.web.client.HttpServerErrorException: 503 Service Unavailable
at org.springframework.web.client.DefaultResponseErrorHandler.handleError(DefaultResponseErrorHandler.java:94)
at org.springframework.web.client.RestTemplate.handleResponse(RestTemplate.java:700)
at org.springframework.web.client.RestTemplate.doExecute(RestTemplate.java:653)
at org.springframework.web.client.RestTemplate.execute(RestTemplate.java:613)
at org.springframework.web.client.RestTemplate.exchange(RestTemplate.java:531)
at com.danlind.igz.ig.api.client.RestAPI.refreshSessionV1(RestAPI.java:778)
at com.danlind.igz.adapter.RestApiAdapter.refreshSessionV1(RestApiAdapter.java:281)
at com.danlind.igz.brokerapi.BrokerLogin.refreshAccessToken(BrokerLogin.java:80)
at com.danlind.igz.brokerapi.BrokerLogin.lambda$startRefreshAccessTokenScheduler$17(BrokerLogin.java:99)
... (removed some lines for brevity)
My code feels pretty straight forward, I can't really understand what would cause this "glitch"? Any ideas? Using RxJava 2.10

Related

Amazon.Runtime.ClientConfig.get_RetryMode() deadlock

I'm running a .net Framework ASP.NET WebApi application on Elastic Beanstalk and it occasionally becomes unresponsive.
We've got some process dumps of w3wp.exe and the blocking thread gets stuck on a call to Amazon.Runtime.ClientConfig.get_RetryMode(). This causes a deadlock as it doesn't release a lock obtained in Amazon.Runtime.Internal.Util.Logger.GetLogger. Subsequent calls get blocked in GetLogger() waiting for the lock to be released which never happens.
Any idea why Amazon.Runtime.ClientConfig.get_RetryMode() doesn't return?
Blocking Call Stack
Amazon.Runtime.ClientConfig.get_RetryMode()+2f
Amazon.Runtime.AmazonServiceClient.BuildRuntimePipeline()+1cd
AWS.Logger.Core.AWSLoggerCore..ctor(AWS.Logger.AWSLoggerConfig, System.String)+1b0
AWS.Logger.Log4net.AWSAppender.ActivateOptions()+131
log4net.Repository.Hierarchy.XmlHierarchyConfigurator.ParseAppender(System.Xml.XmlElement)+47b
log4net.Repository.Hierarchy.XmlHierarchyConfigurator.FindAppenderByReference(System.Xml.XmlElement)+1dc
log4net.Repository.Hierarchy.XmlHierarchyConfigurator.ParseChildrenOfLoggerElement(System.Xml.XmlElement, log4net.Repository.Hierarchy.Logger, Boolean)+110
log4net.Repository.Hierarchy.XmlHierarchyConfigurator.ParseRoot(System.Xml.XmlElement)+5f
log4net.Repository.Hierarchy.XmlHierarchyConfigurator.Configure(System.Xml.XmlElement)+554
log4net.Repository.Hierarchy.Hierarchy.XmlRepositoryConfigure(System.Xml.XmlElement)+c9
log4net.Config.XmlConfigurator.InternalConfigure(log4net.Repository.ILoggerRepository, System.IO.Stream)+2ad
log4net.Config.XmlConfigurator.InternalConfigure(log4net.Repository.ILoggerRepository, System.IO.FileInfo)+18f
log4net.Config.XmlConfigurator.Configure(log4net.Repository.ILoggerRepository, System.Uri)+77
log4net.Core.DefaultRepositorySelector.ConfigureRepository(System.Reflection.Assembly, log4net.Repository.ILoggerRepository)+2d1
log4net.Core.DefaultRepositorySelector.CreateRepository(System.Reflection.Assembly, System.Type, System.String, Boolean)+2bf
log4net.Core.DefaultRepositorySelector.GetRepository(System.Reflection.Assembly)+3e
log4net.Core.LoggerManager.GetLogger(System.Reflection.Assembly, System.Type)+45
[[DebuggerU2MCatchHandlerFrame]]
[[HelperMethodFrame_PROTECTOBJ] (System.RuntimeMethodHandle.InvokeMethod)] System.RuntimeMethodHandle.InvokeMethod(System.Object, System.Object[], System.Signature, Boolean)
mscorlib_ni!System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(System.Object, System.Object[], System.Object[])+84
mscorlib_ni!System.Reflection.RuntimeMethodInfo.Invoke(System.Object, System.Reflection.BindingFlags, System.Reflection.Binder, System.Object[], System.Globalization.CultureInfo)+92
Amazon.Runtime.Internal.Util.InternalLog4netLogger..ctor(System.Type)+d8
Amazon.Runtime.Internal.Util.Logger..ctor(System.Type)+5f
Amazon.Runtime.Internal.Util.Logger.GetLogger(System.Type)+af
Amazon.Runtime.AppConfigAWSCredentials..ctor()+33
Amazon.Runtime.FallbackCredentialsFactory+<>c.b__10_0()+1f
Amazon.Runtime.FallbackCredentialsFactory.GetCredentials(Boolean)+c7
Amazon.SimpleSystemsManagement.AmazonSimpleSystemsManagementClient..ctor(Amazon.RegionEndpoint)+3b
// UserCode new Amazon.SimpleSystemsManagement.AmazonSimpleSystemsManagementClient(region)
Blocked Call Stack
System.Threading.Monitor.Enter(System.Object)
Amazon.Runtime.Internal.Util.Logger.GetLogger(System.Type)+68
Amazon.Runtime.AmazonServiceClient..ctor(Amazon.Runtime.AWSCredentials, Amazon.Runtime.ClientConfig)+8d
// UserCode new Amazon.SimpleSystemsManagement.AmazonSimpleSystemsManagementClient(region)
I think the dead lock was caused by fallback process.
Aws Appender
-> obtain Logger
-> Would release Logger after setting up finish
-> setting up is missing some info , call fallback to figure out
-> failed connection, get_RetryMode()
-> trying to obtain Logger (dead lock generated)

Error "[nodemon] app crashed - waiting for file changes before starting"

[nodemon] restarting due to changes...
[nodemon] starting `node index.js`
backend server is running !
database connect
node:internal/errors:464
ErrorCaptureStackTrace(err);
^
Error [ERR_HTTP_HEADERS_SENT]: Cannot set headers after they are se
nt to the client
at new NodeError (node:internal/errors:371:5)
at ServerResponse.setHeader (node:_http_outgoing:576:11)
at ServerResponse.header (C:\Users\DevTool\Desktop\Project-Reac
t-Final\react\2\ecommerce-site\api\node_modules\express\lib\respons
e.js:776:10)
at ServerResponse.send (C:\Users\DevTool\Desktop\Project-React-
Final\react\2\ecommerce-site\api\node_modules\express\lib\response.
js:170:12)
at ServerResponse.json (C:\Users\DevTool\Desktop\Project-React-
Final\react\2\ecommerce-site\api\node_modules\express\lib\response.
js:267:15)
at C:\Users\DevTool\Desktop\Project-React-Final\react\2\ecommer
ce-site\api\routes\auth.js:38:21
rnal/process/task_queues:96:5) {
code: 'ERR_HTTP_HEADERS_SENT'
}
[nodemon] app crashed - waiting for file changes before starting...
Possibly problem is that you are sending the response in two different places or you are changing something in the res OBJ after sending the res the first time.
To solve this make sure to use the keyword return before sending the response, this way you prevent the code from completing execution.
One small note:
Always providing the code might speed up the process.

Illegal access error when deleting Google Pub Sub subscription upon JVM shutdown

I'm trying to delete a Google Pub Sub subscription in a JVM shutdown hook, but I'm encountering an illegal access error with the Google Pub Sub subscription admin client when the shutdown hook runs. I've tried using both sys.addShutdownHook as well as Runtime.getRuntime().addShutdownHook, but I get the same error either way.
val deleteInstanceCacheSubscriptionThread = new Thread {
override def run: Unit = {
cacheUpdateService. deleteInstanceCacheUpdateSubscription()
}
}
sys.addShutdownHook(deleteInstanceCacheSubscriptionThread.run)
// Runtime.getRuntime().addShutdownHook(deleteInstanceCacheSubscriptionThread)
This is the stack trace:
Exception in thread "shutdownHook1" java.lang.IllegalStateException: Illegal access: this web application instance has been stopped already. Could not load [META-INF/services/com.google.auth.http.HttpTransportFactory]. The following stack trace is thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access.
at org.apache.catalina.loader.WebappClassLoaderBase.checkStateForResourceLoading(WebappClassLoaderBase.java:1385)
at org.apache.catalina.loader.WebappClassLoaderBase.findResources(WebappClassLoaderBase.java:985)
at org.apache.catalina.loader.WebappClassLoaderBase.getResources(WebappClassLoaderBase.java:1086)
at java.util.ServiceLoader$LazyIterator.hasNextService(ServiceLoader.java:348)
at java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:393)
at java.util.ServiceLoader$1.hasNext(ServiceLoader.java:474)
at com.google.common.collect.Iterators.getNext(Iterators.java:845)
at com.google.common.collect.Iterables.getFirst(Iterables.java:779)
at com.google.auth.oauth2.OAuth2Credentials.getFromServiceLoader(OAuth2Credentials.java:318)
at com.google.auth.oauth2.ServiceAccountCredentials.<init>(ServiceAccountCredentials.java:145)
at com.google.auth.oauth2.ServiceAccountCredentials.createScoped(ServiceAccountCredentials.java:505)
at com.google.api.gax.core.GoogleCredentialsProvider.getCredentials(GoogleCredentialsProvider.java:92)
at com.google.api.gax.rpc.ClientContext.create(ClientContext.java:142)
at com.google.cloud.pubsub.v1.stub.GrpcSubscriberStub.create(GrpcSubscriberStub.java:263)
at com.google.cloud.pubsub.v1.stub.SubscriberStubSettings.createStub(SubscriberStubSettings.java:242)
at com.google.cloud.pubsub.v1.SubscriptionAdminClient.<init>(SubscriptionAdminClient.java:178)
at com.google.cloud.pubsub.v1.SubscriptionAdminClient.create(SubscriptionAdminClient.java:159)
at com.google.cloud.pubsub.v1.SubscriptionAdminClient.create(SubscriptionAdminClient.java:150)
at com.company.pubsub.services.GooglePubSubService.$anonfun$deleteSubscription$2(GooglePubSubService.scala:384)
at com.company.utils.TryWithResources$.withResources(TryWithResources.scala:21)
at com.company.pubsub.services.GooglePubSubService.$anonfun$deleteSubscription$1(GooglePubSubService.scala:384)
at com.company.scalalogging.Logging.time(Logging.scala:43)
at com.company.scalalogging.Logging.time$(Logging.scala:35)
at com.company.pubsub.services.GooglePubSubService.time(GooglePubSubService.scala:30)
at com.company.pubsub.services.GooglePubSubService.deleteSubscription(GooglePubSubService.scala:382)
at com.company.cache.services.CacheUpdateService.deleteInstanceCacheUpdateSubscription(CacheUpdateService.scala:109)
at com.company.cache.services.CacheUpdateHandlerService$$anon$1.run(CacheUpdateHandlerService.scala:132)
at com.company.cache.services.CacheUpdateHandlerService$.$anonfun$addSubscriptionShutdownHook$1(CacheUpdateHandlerService.scala:135)
at scala.sys.ShutdownHookThread$$anon$1.run(ShutdownHookThread.scala:37)
It seems like by the time the shutdown hook runs the Pub Sub library has already shut down, so we can't access the subscription admin client anymore. But, I was wondering if there was anyway to delete the subscription before this happens.

Why is Swift Kitura Server Not Terminating Some Threads?

I am having a somewhat reproducible problem on a Swift server I'm running. This is a multi-threaded server, using Kitura. The basics are: After the server has been running for a period of time, download requests start needing retries from the client (usually three retries). The attempts from the client result in the server thread not terminating. On the server, the download problem shows up like this in the log:
[INFO] REQUEST /DownloadFile: ABOUT TO END ...
And then the request never terminates.
The relevant fragment code in my server looks like this:
// <snip>
Log.info(message: "REQUEST \(request.urlURL.path): ABOUT TO END ...")
do {
try self.response.end()
Log.info(message: "REQUEST \(request.urlURL.path): STATUS CODE: \(response.statusCode)")
} catch (let error) {
Log.error(message: "Failed on `end` in failWithError: \(error.localizedDescription); HTTP status code: \(response.statusCode)")
}
Log.info(message: "REQUEST \(request.urlURL.path): COMPLETED")
// <snip>
That is, the server clearly seems to hang on the call to end (a Kitura method). See also https://github.com/crspybits/SyncServerII/blob/master/Sources/Server/Setup/RequestHandler.swift#L105
Immediately before this issue came up last time, I observed the following in my server log:
[2017-07-12T15:31:23.302Z] [ERROR] [HTTPServer.swift:194 listen(listenSocket:socketManager:)] Error accepting client connection: Error code: 5(0x5), ERROR: SSL_accept, code: 5, reason: DH lib
[2017-07-12T15:31:23.604Z] [ERROR] [HTTPServer.swift:194 listen(listenSocket:socketManager:)] Error accepting client connection: Error code: 1(0x1), ERROR: SSL_accept, code: 1, reason: Could not determine error reason.
[2017-07-12T15:31:23.995Z] [ERROR] [HTTPServer.swift:194 listen(listenSocket:socketManager:)] Error accepting client connection: Error code: 1(0x1), ERROR: SSL_accept, code: 1, reason: Could not determine error reason.
[2017-07-12T15:40:32.941Z] [ERROR] [HTTPServer.swift:194 listen(listenSocket:socketManager:)] Error accepting client connection: Error code: 1(0x1), ERROR: SSL_accept, code: 1, reason: Could not determine error reason.
[2017-07-12T15:42:43.000Z] [VERBOSE] [HTTPServerRequest.swift:215 parsingCompleted()] HTTP request from=139.162.78.135; proto=https;
[INFO] REQUEST RECEIVED: /
[2017-07-12T16:32:38.479Z] [ERROR] [HTTPServer.swift:194 listen(listenSocket:socketManager:)] Error accepting client connection: Error code: 1(0x1), ERROR: SSL_accept, code: 1, reason: Could not determine error reason.
I am not sure where this is coming from in the sense that I'm not sure if one of my client's is generating this. I do not explicitly make requests to my server with "/". (I do occasionally see requests made to my server from clients that are not mine-- it is possible this is one of these). Note that all except one of these log messages are coming from Kitura, not directly from my code. My log message is [INFO] REQUEST RECEIVED: /.
If I was a betting man, I'd say the above errors put my server into a state where afterwards, I see this download/retry behavior.
My only solution at this point is to restart the server. From which point the issue doesn't immediately happen.
Thoughts?
I'm not sure if this addresses the root problem, or if it's just a work-around, but it appears to be working. With the server as stated in the question, I had been using Kitura's built-in SSL support. I have now switched to using NGINX as a front-end, and no longer use Kitura's built-in SSL support. NGINX takes care of all the HTTPS/SSL details. Since doing this (about a month ago), and with the server running for all of that intervening time, I have not experience the not terminating issue reported in this question. See also https://github.com/crspybits/SyncServerII/issues/28

WebView returning blank post FB authorization

From my react native application, I am trying to authenticate against FB. Instead of directly using fbsdk, I was planning to use a wrapper around it.
I tried two wrappers.
https://github.com/xxsnakerxx/react-native-social-auth
https://github.com/magus/react-native-facebook-login
In both cases, I end up with a WebView which won't callback the app.
I have raised two issues
https://github.com/magus/react-native-facebook-login/issues/187
https://github.com/xxsnakerxx/react-native-social-auth/issues/6
XCode logs has below entries which I am not able to decipher
2016-12-09 06:13:29.757 XXXX[61829:8555589] -canOpenURL: failed for URL: "fbauth2:/" - error: "The operation couldn’t be completed. (OSStatus error -10814.)"
2016-12-09 06:13:29.759 XXXX[61829:8555589] -canOpenURL: failed for URL: "fbauth2:/" - error: "The operation couldn’t be completed. (OSStatus error -10814.)"
and..
__nw_socket_service_writes_block_invoke sendmsg(fd 9, 31 bytes): socket has been closed
2016-12-09 06:13:36.670958 XXXX[61829:8574160] [] nw_endpoint_flow_protocol_error [15.1 157.240.7.20:443 cancelled socket-flow (null)] Socket protocol sent error: [32] Broken pipe
2016-12-09 06:13:36.671154 XXXX[61829:8574160] [] nw_endpoint_flow_protocol_disconnected [15.1 157.240.7.20:443 cancelled socket-flow (null)] Output protocol disconnected
And the WebView post all the authentication looks like
Eventually successful with react-native-social-auth. Missed a few configurations.