I have about 30 instances running and submitting data to dynamo, but in my logs, I'm getting a ton of ConditionalCheckFailedException failure messages. The weird thing is, I'm not saving with any conditional check, unless I'm missing something:
private void save(DynamoObject myObject) {
try {
mapper.save(model);
} catch (ConditionalCheckFailedException e) {
// metrics and logging
} catch (Exception e) {
// metrics and logging
}
What could be causing this?
It looks like you are using DynamoDBMapper and specifically #DynamoDBVersionAttribute somewhere and your put item failure is related to the mapper's optimistic locking strategy. The item version on the server is different to that on the client side because of another write to that item, so DynamoDB rejects the put.
You'll need to reconcile the item differences client-side and re-submit.
Related
After reading upon Database SQL best practices, i have extracted two try catches into two separate methods. The only thing that I can think of which create a Database leak is if there is an external unhanded exception after doing getReadableDatabase(). So my question is, if an app crashes and restarts does the app clean itself up? For example help me closing this database session? As you can see i don't fully quite understand what happens after an App crashes/ restarts.
try {
SQLiteDatabase database = helper.getReadableDatabase();
doALongDatabaseTask(database);
database.close();
} catch (SQLException e){
Log.w(Util.TAG, "getButtonPairsForSending db cannot be opened " + e);
}
public void doALongDatabaseTask(SQLiteDatabase database){
try
{
// Do long database query task
} catch(Exception e) {
}
}
In your example method doALongDatabaseTask(SQLiteDatabase database) the exception is handled, its just nothing is done with it, so in this case your database would call close()
However, if your method was defined to throw an exceptions
public void doALongDatabaseTask(SQLiteDatabase database) throws Exception{...}
then your call to close would be skipped, as it goes into the catch block in the first part of the example given.
Provided your using a high enough sdk version: If you look at the docs for SQLiteDatabase you can see that it implements the interface AutoCloseable.
This means that you can use a try with resources which looks like this
try(SQLiteDatabase database = helper.getReadableDatabase()){
doALongDatabaseTask(database);
} catch (Exception e) {
e.printstacktrace();
}
This is the equivalent of calling database.close() in a finally block (which you should be doing anyway) but much more readable. This then should in most cases clean up the connections when your app crashes and on a restart fresh connections can be obtained.
While trying to develop an application that interacts with some cloud services I found the Dropbox API for Java to be especially confusing.
Specifically how to find the HTTP errors. For instance, with the Google Drive API if a request fails an IOException will be thrown however you can parse that IOException into a GoogleJsonResponseException which you can then extract the status code.
try {
File f =drive.files().create(fileMetadata).setFields("id").execute();
return f.getId();
} catch (IOException e) {
if (e instanceof GoogleJsonResponseException){
int statusCode = ((GoogleJsonResponseException) e).getStatusCode();
errorHandler(statusCode);
} else {
e.printStackTrace();
}
}
So is there something like this in the java dropbox API (Specifically 3.0.5).
I have been looking around and it seems like no but I wanted to make sure before I go down the rabbit hole of extremely specialized and complex coding like mentioned here. If it is could someone please give me an example of how I could properly handle these exceptions.
[Cross-linking for reference: https://www.dropboxforum.com/t5/API-support/How-to-get-error-responses-java-api/m-p/258338#M14989 ]
The Dropbox Java SDK automatically parses out the structured error data from the HTTPS response into native classes, and you can use as much or little of that specificity as you want. The structured error responses (generally JSON in the response body) offer much more granularity than just status codes.
For example, here's the code sample that is now missing from StackOverflow documentation from my post that you linked to:
try {
SharedLinkMetadata sharedLinkMetadata = client.sharing().createSharedLinkWithSettings("/test.txt");
System.out.println(sharedLinkMetadata.getUrl());
} catch (CreateSharedLinkWithSettingsErrorException ex) {
System.out.println(ex);
} catch (DbxException ex) {
System.out.println(ex);
}
And here's an example that shows how to check for a particular error case (i.e., a "path" error in that example).
That's the recommended way of handling these exceptions. I don't believe the SDK offers a way to retrieve the original unparsed error response. (If you don't want to use the SDK though, you can call the HTTPS endpoints yourself directly.)
I have a service that is expected to execute requests at ~5 or more requests/min. This service depends on Apache AsyncHttpClient. After every few minutes, the clients hits some condition which causes java.lang.IllegalStateException: Request cannot be executed; I/O reactor status: STOPPED. All requests to the client start failing with same exception message. After service is restarted, this cycle repeats.
It is really hard to debug this problem as the request execution failure surprisingly does not cause a callback to the failed() method of the AsyncResponse.
From what I could gather, there has been a fix HTTPCORE-370 in HttpCore NIO which solved a similar problem in 4.3.2. I am using the following version -
commons-httpclient-3.1.jar
httpasyncclient-4.1.1.jar
httpcore-4.4.4.jar
httpcore-nio-4.4.4.jar
Yet seeing this problem.
I've been dealing with this same exception in my application, and I finally found a helpful suggestion from this post - http://httpcomponents.10934.n7.nabble.com/I-O-reactor-status-STOPPED-td29059.html
You can use #getAuditLog() method of the I/O reactor to find out exactly
what exception caused it to terminate.
If you keep a reference to your ConnectionManager's IOReactor, you can call this method to get insight into the actual problem:
http://hc.apache.org/httpcomponents-core-4.4.x/httpcore-nio/apidocs/org/apache/http/impl/nio/reactor/AbstractMultiworkerIOReactor.html#getAuditLog()
Turns out I was doing something incredibly stupid in my own code. But I couldn't figure it out until I read the audit log.
If you see OutOfMemoryError before this, try this
-XX:MaxDirectMemorySize=512M
See https://issues.apache.org/jira/browse/HTTPASYNC-104
In my case, using Elasticsearch high level client, this exception is due to esclient.indexAsync(indexRequest,RequestOptions.DEFAULT,null)
I fixed it by add an action listeners in all async requests like this
esclient.indexAsync(indexRequest,RequestOptions.DEFAULT,
new ActionListener<IndexResponse>() {
#Override
public void onResponse(IndexResponse response) {
}
#Override
public void onFailure(Exception e) {
});
We had encountered the same issue and after lots of digging we found that a proper IOReactorExceptionHandler needs to provided to the HttpAsyncClient to avoid this. It's unfortunate that it's not well covered in the documentation.
Below is a snippet of our code where a more robust client builder tries to add the exception handler. Note that IOExceptions would still stop the I/O reactor as they might imply underlying network communication failures. You may adjust according to your unique use cases.
public RobustCloseableHttpAsyncClientBuilder withDefaultExceptionHandler() {
return withExceptionHandler(
new IOReactorExceptionHandler() {
#Override
public boolean handle(RuntimeException ex) {
logger.error(
"RuntimeException occurs in callback, handled by default exception handler and the I/O reactor will be resumed.",
ex);
return true;
}
#Override
public boolean handle(IOException ex) {
logger.error(
"IOException occurs in callback, handled by default exception handler and the I/O reactor will be stopped.",
ex);
return false;
}
});
}
Read this issue report in elasticsearch on Github for more exposure.
I have three different types of server connection. These can be configured in properties file.
Say there are three servers:
Server1
Server2
Server3
In Properties file, I've configured as below:
ServerPref1 = Server1
ServerPref2 = Server2
ServerPref3 = Server3
In code level, my fall back mechanism is as below:
private static void getServerAndConnect() {
try {
connect(Properties.ServerPref1);
} catch (ServerException se1) {
try {
connect(Properties.ServerPref2);
} catch (ServerException se2) {
try {
connect(Properties.ServerPref3);
} catch (ServerException se3) {
// Unable to connect
}
}
}
}
The connect() method will throw custom ServerException, if unable to connect to server.
Everything works as expected.
My question is: Is this the correct or best way to implement fallback mechanism?
I'd recommend a list of server connections then you can use a loop instead of nesting, this will let you add more servers without code changes.
Since you have separate attributes for each connection the best I can offer without seeing the rest of your code is to put those fields into a temporary list and loop over that.
Ideally make your properties parsing code write the connections into a List as well so you can have arbitrary number of servers without adding new fields to your Properties class.
private static void getServerAndConnect() {
List<ServerPref> serverPrefs = Arrays.asList(Properties.ServerPref1, Properties.ServerPref2, Properties.ServerPref3);
for (ServerPref serverPref : serverPrefs) {
try {
connect(serverPref);
// test success of connection? and break out of the loop
break;
} catch (ServerException se1) {
// log error and go onto next one
}
}
}
The general approach is ok. Depending on your needs you could make a few improvements:
Are there always exactly three servers? If than number can change, put your servers in a list, and iterate over that list to find the first functioning server.
If you want your work load more evenly distributed over the servers, instead of all connections going to the first server if it is available, randomize the list of servers before you iterate ofver it, or use a round robin approach.
If the getServerAndConnect() method is called often, consider remembering the server that was used eventually, and use that first the next time, since the probability is hight that is still is reachable.
I'm calling a method which involves lots of fetching and updating tables that might take 10+ minutes. This is done using a background thread so that the UI is responsive and the user doesn't have to wait for it to complete.
There are chances that an exception might be raised. In that case, I need to udpate the status of a column from "Pending" to "Failed".
Is it fine to do this in the catch block? Can I write a code in the catch block such that a query is executed to update the status to failed? Is this the right way or are there any other ways to do this?
Edit: Can I do something like this, so that when an exception is thrown, the status gets updated to "Failed" and the exception stack trace is printed out?
catch (Exception e) {
updateStatusByReqId(reqKey, "F");
e.printStackTrace();
}
Will this ensure that if there are any exceptions, the status of the request gets changed to "Failed"? Note that on creating the request online, the request will be having the status "Pending". It should remain pending if everything is fine, otherwise changed to "Failed"
If you write the code to update the status in the catch block it will work fine, however since you are inside a method maybe could be better return a boolean value from the methos and update the ui from the caller of the thread, something like this :
private boolean updateDatabase() {
try {
//Your long updating code ...
} catch {
return false;
}
return true;
}
Then you can call the method from the background thread and, log the status in the UI if it return false :
if(!updateDatabase()) {
//Update UI status
}
Doing in this way it is a better style, from my point of view ...
I wouldn't put the code in the catch block. Put the logic to for updating the status (on the GUI?) in a separate class and method and call it:
String currentColumn = "";
try {
// ...
} catch (SomeExceptions se) {
updateColumnStatus(currentColumn, se); // local method / KISS
continue; // we're in a loop, right?
}
It is fine to write error related code in catch block!
It looks like the exception is some kind of 'normal' busing flow (like validation). So, short answer is you can do some processing in catch block.
Caution: While you can write almost any thing in catch block, prefer to do error handling or error recovery in catch blocks.
What happens the exception was related to database access? You would not able to update the
column to 'failed'. You anyway need to have some additional processing in this case. Why not use the same in all cases?