I am developing an app in Java (Kotlin :X) that uses the Google Photos Api.
I am stuck in a flow where I may want to cancel the current client initialization attempt and try again.
val settings = PhotosLibrarySettings.newBuilder()
.setCredentialsProvider(
FixedCredentialsProvider.create(
getUserCredentials(credentialsPath, SCOPES, email)
)
)
.build()
// let the Thread hanging until a successful initialization :/
return PhotosLibraryClient.initialize(settings)
But unfortunately, I did not find any way to do this besides enveloping the PhotosLibraryClient.initialize(settings) call in a Thread and calling the deprecated method Thread#stop().
If I do this call twice (on different threads), without successfully stopping one of the client initializations, the following exception is thrown: java.io.IOException: java.net.BindException: Address already in use (Bind failed).
How can I successfully stop a client initialization attempt without calling Thread#stop()?
Related
At medium to high load (test and production), when using the Vert.x Redis client, I get the following warning after a few hundred requests.
2019-11-22 11:30:02.320 [vert.x-eventloop-thread-1] WARN io.vertx.redis.client.impl.RedisClient - No handler waiting for message: [null, 400992, <data from redis>]
As a result, the handler supplied to the Redis call (see below) does not get called and the incoming request times out.
Handler<AsyncResult<String>> handler = res -> {
// success handler
};
redis.get(key, res -> {
handler.handle(res);
});
The real issue is that once the "No handler ..." warning comes up, the Redis client becomes useless because all further calls to Redis made via the client fails with the same warning resulting in the handler not getting called. I have an exception handler set on the client to attempt reconnection, but I do not see any reconnections being attempted.
How can one recover from this problem? Any workarounds to alleviate the severity would also be great.
I'm on vertx-core and vertx-redis-client 3.8.1 .
The upcoming 4.0 release had addressed this issue and a release should be hapening soon, how soon, I can't really tell.
The problem is that we can't easily port back from the master branch to the 3.8 branch because a major refactoring has happened on the client and the codebases are very different.
The new code, uses a connection pool and has been tested for concurrent access (and this is where the issue you're seeing comes from). Under load the requests are routed across all event loops and the queue that maintains the state between in flight requests (requests sent to redis) and waiting handlers would get out of sync in very special conditions.
So I'd first try to see if you can already start moving your code to 4.0, you can have a try with the 4.0.0-milestone3 version but to be totally fine, just have a run with the latest master which has more issues solved in this area.
I am trying to capture all method calls made in any android app. For that I am using JDI to register MethodEntryRequest for each running thread of the app. I am successful to do this, but I am facing the problem that the app becomes very very slow. So I want to know if I am doing anything wrong in my implementation. I am adding my code where I first register ClassPreparedRequest to catch loading of each class by app process and in that I register MethodEntryRequest with threadfilter for thread which caused the class to load.
if(!traceMap.keySet().contains(event.thread()))
{
EventRequestManager mgr = vm.eventRequestManager();
MethodEntryRequest menr = mgr.createMethodEntryRequest();
menr.setSuspendPolicy(EventRequest.SUSPEND_NONE);
menr.addThreadFilter(event.thread());
menr.enable();
}
Code for registering ClassPreparedRequest is
ClassPrepareRequest cpr = mgr.createClassPrepareRequest();
cpr.addClassFilter("com.example.*");
cpr.setSuspendPolicy(EventRequest.SUSPEND_NONE);
cpr.enable();
I am attempting to create an Android app which collects a variety of remote song links and plays them out for users. The app uses Android's MediaPlayer, and every single song link redirects to a Stream URL which the MediaPlayer handles and eventually plays out.
However, some of these song links actually redirect and provide a HTTP 404 Error as they are not available, and I want to know if there is any way to directly handle/catch for these HTTP errors instantly. As of now, what the MediaPlayer does is signal out a:
error (1, -2147483648)
... after it attempts to connect with the data source 10 times, which I can then catch to notify the user that the song is unavailable.
Of course though, having the user wait for 10 retries takes far too much time, and so I want to know if there is a way to catch the very first moment the HTTP error occurs from the MediaPlayer without having to check the URL before sending it to the MediaPlayer, or having to hack away and manage the exceptions with a network proxy connected to the MediaPlayer.
Exception given by MediaPlayer 10 times:
07-16 05:16:30.549: E/MediaHTTPConnection(16698): IOException: java.io.IOException: Http Response: 404
If the error pops up 10 times, and each time an error is put out, then I don't see why a simple try-catch loop will not work:
try {
// download URL
} catch (IOException e) {
// presumably an exception is thrown the first time it gets 404 so put the error handling code here
}
Also, might I suggest using multithreading to download from URLs using something like the ExectutorService which allows you to submit Runnable classes to it and run them concurrently (i.e. the download Tasks for each video so they download at the same time)
Clearcase Resource proxy, CcFile instance, holding a file in working snapshot view, is throwing exception while invoked resolve() method. Whereas, it keep waiting forever, when invoked doResolve() method which contacts the clearcase server.
Code used for retrieving the proxy class:
StpProvider provider = (StpProvider) ProviderFactory.createProvider(CcProvider.NETWORK_PROVIDER_CLASS, callback);
provider.setServerUrl(serverUrl);
provider = provider.ccProvider();
StpLocation loc = provider.filePathLocation(Domain.CLEAR_CASE, new File("windowsDrive:/folders/fileName.sql"));
CcFile proxy = provider.ccFile(loc);
proxy.doResolve(); //This method supposed to invoke CC server and update proxy information, but it's keep waiting forever.
(or)
proxy.resolve();
Throws below exception:
Exception in thread "main" CcException: CRMAP7013: File is not in a
ClearCase view: cc.file:windowsDrive:/folders/fileName.sql
reason: client-location-not-in-file-area
resource: null at
com.ibm.rational.stp.client.internal.cc.CcFileAreaFactory.locationToClientState(CcFileAreaFactory.java:114)
at
com.ibm.rational.stp.client.internal.cc.CcFileImpl.getClientState(CcFileImpl.java:174)
at
com.ibm.rational.stp.client.internal.cc.CcFileImpl.readProperties(CcFileImpl.java:660)
at
com.ibm.rational.stp.client.internal.cc.CcFileImpl.resolve(CcFileImpl.java:652)
Any help on how to proceed will be appreciated.
Root cause being that Clearcase client does not support snapshot views in my client/server version 8.0.0.10. This feature is only added after 8.1. So, i switched to dynamic view and this problem is now resolved.
I'm trying to start a Amazon EC2 cloud machine with [startInstance][2] method using aws-sdk in Java. My code is as follows.
public String startInstance(String instanceId) throws Exception {
List<String> instanceIds = new ArrayList<String>();
instanceIds.add(instanceId);
StartInstancesRequest startRequest = new StartInstancesRequest(
instanceIds);
startRequest.setRequestCredentials(getCredentials());
StartInstancesResult startResult = ec2.startInstances(startRequest);
List<InstanceStateChange> stateChangeList = startResult
.getStartingInstances();
log.trace("Starting instance '{}':", instanceId);
// Wait for the instance to be started
return waitForTransitionCompletion(stateChangeList, "running",
instanceId);
}
When I run the above code, i'm getting the following AWS error:
Status Code: 400, AWS Request ID: e1bd4795-a609-44d1-9e80-43611e80006b, AWS Erro
r Code: InvalidInstanceID.NotFound, AWS Error Message: The instance ID 'i-2b97ac
2f' does not exist
at com.amazonaws.http.AmazonHttpClient.handleErrorResponse(AmazonHttpCli
ent.java:538)
at com.amazonaws.http.AmazonHttpClient.executeHelper(AmazonHttpClient.ja
va:283)
at com.amazonaws.http.AmazonHttpClient.execute(AmazonHttpClient.java:168
)
at com.amazonaws.services.ec2.AmazonEC2Client.invoke(AmazonEC2Client.jav
a:5208)
at com.amazonaws.services.ec2.AmazonEC2Client.startInstances(AmazonEC2Cl
ient.java:2426)
AWS Error Message: The instance ID 'i-2b97ac2f' does not exist
You'll have to take the AWS response for granted here, i.e. the instance does not exist ;)
But seriously: Presumably you have already verified that you are actually running an instance with this ID in your account? Then this is most likely caused by targeting the wrong API endpoint, insofar an instance ID is only valid within a specific region (if not specified, the region defaults to 'us-east-1', see below).
In this case you need to specify the actual instance region via the setEndpoint() method of the AmazonEC2Client object within the apparently global ec2 variable before calling startInstances().
There are some examples regarding Using Regions with the AWS SDKs and all currently available AWS regional endpoint URLs are listed in Regions and Endpoints, specifically the Amazon Elastic Compute Cloud (EC2) defaults to 'us-east-1':
If you just specify the general endpoint (ec2.amazonaws.com), Amazon
EC2 directs your request to the us-east-1 endpoint.
We run a service (Qubole) that frequently spawns and then tags (and in some cases terminates) AWS instances immediately.
We have found that Amazon will, every once in a while, claim an instanceid as invalid - even though it has just created it. Retrying a few times with some sleep time thrown in usually solves the problem. Even a total retry interval of 15s proved insufficient in rare cases.
This experience comes from the useast region. We do not make api calls to different regions - so that is not an explanation. More likely - this is the infamous eventual consistency at work - where AWS is unable to provide read-after-write consistency for these api calls.
I am using the AWS ruby api and I noticed the same issue when creating an AMI image and its status is pending when I look in the AWS console but after a while the image is available for use.
Here is my script
image = ec2.images.create(:name => image_name, :instance_id => ami_id, :description => desc)
sleep 5 while image.state != :available
I sleep for about 5 sec for image to be in available but I get the error saying that the "AWS Error Message: InvalidInstanceID.NotFound". During my testing this is fine but most of the time this seems to be failing during continuous integration builds.
InvalidInstanceID.NotFound means the specified instance does not exist.
Ensure that you have indicated the region in which the instance is located, if it's not in the default region.
This error may occur because the ID of a recently created instance has not propagated through the system. For more information, see Eventual Consistency.