Develop Reference

AWS SDK is throwing SdkClientException

I am attempting to retrieve a secret from aws secrets manager. My application can retrieve 3 / 4 secrets. When attempting to retrieve the 2nd secret, i get an interrupt exception. The code below is what i am using. I am unsure where to look or why this is happening. It consistently happens when attempting to retrieve the 2nd secret. I have verified that it exists in aws and that it contains the value i expect.
I am using the reativerse [https://github.com/reactiverse/aws-sdk] library in tandem with vert.x + aws sdk 2. Any help or pointers on where to look would be greatly appreciated. The exception i see and the code i have are written below.
java.util.concurrent.ExecutionException: software.amazon.awssdk.core.exception.SdkClientException
at java.base/java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:395)
at java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1999)
at io.vertx.core.impl.ContextImpl.lambda$null$0(ContextImpl.java:159)
at io.vertx.core.impl.AbstractContext.dispatch(AbstractContext.java:100)
at io.vertx.core.impl.ContextImpl.lambda$executeBlocking$1(ContextImpl.java:157)
at io.vertx.core.impl.TaskQueue.run(TaskQueue.java:76)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: software.amazon.awssdk.core.exception.SdkClientException
at software.amazon.awssdk.core.exception.SdkClientException$BuilderImpl.build(SdkClientException.java:98)
at software.amazon.awssdk.core.internal.http.AmazonAsyncHttpClient$RequestExecutionBuilderImpl.execute(AmazonAsyncHttpClient.java:189)
at software.amazon.awssdk.core.internal.handler.BaseAsyncClientHandler.invoke(BaseAsyncClientHandler.java:271)
at software.amazon.awssdk.core.internal.handler.BaseAsyncClientHandler.doExecute(BaseAsyncClientHandler.java:213)
at software.amazon.awssdk.core.internal.handler.BaseAsyncClientHandler.lambda$execute$1(BaseAsyncClientHandler.java:91)
at software.amazon.awssdk.core.internal.handler.BaseAsyncClientHandler.measureApiCallSuccess(BaseAsyncClientHandler.java:277)
at software.amazon.awssdk.core.internal.handler.BaseAsyncClientHandler.execute(BaseAsyncClientHandler.java:74)
at software.amazon.awssdk.awscore.client.handler.AwsAsyncClientHandler.execute(AwsAsyncClientHandler.java:52)
at software.amazon.awssdk.services.secretsmanager.DefaultSecretsManagerAsyncClient.getSecretValue(DefaultSecretsManagerAsyncClient.java:1142)
... 8 more
Caused by: software.amazon.awssdk.core.exception.SdkInterruptedException
at software.amazon.awssdk.core.internal.http.InterruptMonitor.checkInterrupted(InterruptMonitor.java:40)
at software.amazon.awssdk.core.internal.http.pipeline.stages.ApplyTransactionIdStage.execute(ApplyTransactionIdStage.java:43)
at software.amazon.awssdk.core.internal.http.pipeline.stages.ApplyTransactionIdStage.execute(ApplyTransactionIdStage.java:29)
at software.amazon.awssdk.core.internal.http.pipeline.RequestPipelineBuilder$ComposingRequestPipelineStage.execute(RequestPipelineBuilder.java:206)
at software.amazon.awssdk.core.internal.http.pipeline.RequestPipelineBuilder$ComposingRequestPipelineStage.execute(RequestPipelineBuilder.java:206)
at software.amazon.awssdk.core.internal.http.pipeline.RequestPipelineBuilder$ComposingRequestPipelineStage.execute(RequestPipelineBuilder.java:206)
at software.amazon.awssdk.core.internal.http.pipeline.RequestPipelineBuilder$ComposingRequestPipelineStage.execute(RequestPipelineBuilder.java:206)
at software.amazon.awssdk.core.internal.http.pipeline.RequestPipelineBuilder$ComposingRequestPipelineStage.execute(RequestPipelineBuilder.java:206)
at software.amazon.awssdk.core.internal.http.pipeline.RequestPipelineBuilder$ComposingRequestPipelineStage.execute(RequestPipelineBuilder.java:206)
at software.amazon.awssdk.core.internal.http.AmazonAsyncHttpClient$RequestExecutionBuilderImpl.execute(AmazonAsyncHttpClient.java:185)
... 16 more
private final SecretsManagerAsyncClient client = VertxSdkClient.withVertx(SecretsManagerAsyncClient.builder(), ctx).build();
public <T> Promise<T> getSecret(String secretName) {
Promise<T> completableFuture = Promise.promise();
Context ctx = Vertx.vertx().getOrCreateContext();
ctx.owner().executeBlocking(blockingFuture -> {
try {
GetSecretValueRequest valueRequest = GetSecretValueRequest.builder().secretId(secretName).build();
CompletableFuture<GetSecretValueResponse> valueResponse = this.client.getSecretValue(valueRequest);
GetSecretValueResponse getResponse = valueResponse.get();
String response = getResponse.secretString();
completableFuture.complete((T) Json.decodeValue(response, new <T>Object().getClass()));
blockingFuture.complete();
} catch (Exception e) {
// log exception.
}
});
...
}

See SdkInterruptedException ...it has one method getResponse():
try {
// provoke the exception in here
} catch (SdkInterruptedException e) {
System.err.println(e.getResponse());
}
This should (hopefully) at least tell why the request had been interrupted.
// log exception. is not the correct approach to handle any Exception.
The SdkClientException might be more relevant than the SdkInterruptedException:
try { ...
} catch (SdkClientException e) {
// log that exception, instead of ignoring it.
System.err.println(e.getMessage());
}
This is how an Authorization Header (AWS Signature Version 4) should basically look alike.
It may well be, that HMAC-SHA256 headers are being enforced (they're different on each single request). I could even provide a known to be working example... which would show how to configure the SecretsManagerClient. I'd suspect the root cause related to that client's configuration.
When I read "when attempting to retrieve the 2nd secret", this with high probability means that you need a refresh the HMAC-SHA256 signature before the second request will be performed. Destroying the client and constructing it again may be one sloppy workaround. When seeing duplicate values for AWS4-HMAC-SHA256 header on both requests, this definitely is the cause.

MarkLogic Java API Exception Throwing Method

In Java API, No Exception is thrown, albeit erroneous transaction:
try {
…………………………………
logger.info("Delete Document " + uri);
docMgr.delete("rocky-mountains");
System.out.println("Deleted");
} catch (Exception e) {
logger.error("Exception : " + e.toString() );
}
Document rocky-mountains doesn’t exist, however, the API happily declares Deleted:
Jul 05, 2020 9:35:04 PM com.fc.allegro.DeleteDocument deleteDocument
INFO: Delete Document rocky-mountains
Jul 05, 2020 9:35:04 PM com.marklogic.client.impl.DocumentManagerImpl delete
INFO: Deleting rocky-mountains
Deleted
In Query Console, eval detects and throws error:
[1.0-ml] XDMP-DOCNOTFOUND: xdmp:document-delete("rocky-mountains") -- Document not found
As the lesser of two evils, DMSDK implies no document deleted but still doesn’t throw exception:
QueryBatcher batcher = dmManager.newQueryBatcher(new StructuredQueryBuilder().document("rocky-mountains"));
batcher.onUrisReady(new DeleteListener())
.onQueryFailure( exception -> exception.printStackTrace() );
Result:
Jul 05, 2020 9:52:07 PM com.marklogic.client.datamovement.impl.QueryBatcherImpl withForestConfig
INFO: (withForestConfig) Using forests on [localhost] hosts for "allegro"
Batch Deleted
INFO: Job complete, jobBatchNumber=1, jobResultsSoFar=0
I tried checked and unchecked exceptions, but to no avail.
Which MarkLogic Class and Method does enforce throwing exceptions and mitigate risk?
A query transaction via Java API:
Failure:
Success:

There is an important difference between running xdmp:document-delete and using Java API to delete a document. The Java API is a wrapper for the MarkLogic REST-API, which follows the rules for a RESTful API. One important rule of a RESTful API is that calls are expected to be idempotent. In short that means that you should be able to run the call twice and get same reply both times. That is why calls to insert, update, and delete don't throw errors if the document does or does not exist.
See also for instance: https://restfulapi.net/http-methods/#delete
I'd recommend using Data Services, or custom REST extensions if you want your app to be more strict.
HTH!

How to catch "Unable to sendViaPost to url"?

I am running two axis2 services which communicate with each other. On every service startup I get this error:
2014-02-24 13:02:31,258 [INFO ] HTTPSender - Unable to sendViaPost to url[http://127.0.0.1:8081/axis2/services/MYSERVICE1.MYSERVICE1HttpSoap12Endpoint/]
java.net.ConnectException: Connection refused: connect
at java.net.DualStackPlainSocketImpl.waitForConnect(Native Method)
at java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:85)
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:579)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.apache.commons.httpclient.protocol.ReflectionSocketFactory.createSocket(ReflectionSocketFactory.java:140)
at org.apache.commons.httpclient.protocol.DefaultProtocolSocketFactory.createSocket(DefaultProtocolSocketFactory.java:125)
at org.apache.commons.httpclient.HttpConnection.open(HttpConnection.java:707)
at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$HttpConnectionAdapter.open(MultiThreadedHttpConnectionManager.java:1361)
at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:387)
at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
at org.apache.axis2.transport.http.AbstractHTTPSender.executeMethod(AbstractHTTPSender.java:621)
at org.apache.axis2.transport.http.HTTPSender.sendViaPost(HTTPSender.java:193)
at org.apache.axis2.transport.http.HTTPSender.send(HTTPSender.java:75)
at org.apache.axis2.transport.http.CommonsHTTPTransportSender.writeMessageWithCommons(CommonsHTTPTransportSender.java:404)
at org.apache.axis2.transport.http.CommonsHTTPTransportSender.invoke(CommonsHTTPTransportSender.java:231)
at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:443)
at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:406)
at org.apache.axis2.description.OutInAxisOperationClient$NonBlockingInvocationWorker.run(OutInAxisOperation.java:446)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:724)
Since this error is not important, I would like to catch it and to print some better error message instead of the whole stack trace. Where do I catch this error?

Looking at the stack trace, I don't think you can catch it. Catching it would require that you own code somewhere in the Thread where the exception is being thrown.
Looking at the lowest stack in the trace shows this:
at java.lang.Thread.run(Thread.java:724)
To me this says that the exception is occurring in a thread most likely started by Axis. Because of this you can't catch it and show an error message.
If this is expected behavior, the best you can do is to configure your logging framework not to show INFOs from Axis. Be aware that this may mean you'll also miss more useful error messages as well.
All in all, I would focus on how to solve the "Unable to sendViaPost" from happening rather than suppressing the logging statement.
To answer your comment question: As you can see from the stack trace, the exception is not caught by any client code but is bubbled up to Thread itself. This is the stopping point for an Exception and where it stops. If you were going to catch it you'd have to have code in its call stack (which you don't, since when the thread is created by Axis a new call stack is created for the new thread Axis starts).
Read more here. The only difference in your case is that since the exception is not thrown on the main thread the program doesn't exit, but the thread where the exception occurs is terminated.
To sum it up: You have no code in the call stack and therefore cannot catch the exception. The only other option is to turn of INFO statements for Axis.

If I am understanding the question properly you're attempting to catch something that is not the exception that is being thrown.
This:
HTTPSender - Unable to sendViaPost to url[http://127.0.0.1:8081/axis2/services/MYSERVICE1.MYSERVICE1HttpSoap12Endpoint/]
is what is being attempted. When it failed it's throwing a ConnectException.
Which you can simply catch with
try{
//Code that Makes the Connection
}
catch (ConnectException e)
{
e.printStackTrace();//Or What ever your message may be
}
Without seeing some code it's impossible to give a definitive answer. But this likely will solve the problem.
One Caveat, if you do catch a ConnectException to suppress it, you could suppress when there actually is a problem that would also throw a ConnectException.
If this is happening when you are starting up the server you might want to check why this is happening before trying to suppress it.
If it's refusing the connection that you are attempting you might want to ensure where it is connecting to has an available socket to connect to.

2014-02-24 13:02:31,258 [INFO] HTTPSender - Unable to
sendViaPost to
url[http://127.0.0.1:8081/axis2/services/MYSERVICE1.MYSERVICE1HttpSoap12Endpoint/]
Well, if you look closely, the message which you are trying to catch isn't an ERROR at all. It's an INFO log generated from HTTPSender. Only thing which you should catch in this entire stacktrace is java.net.ConnectException and check for message Connection refused.
You can make it easier for your clients though and provide a message, by wrapping the java.net.ConnectException with message Connection refused or throwing a custom exception with the original exception as the cause.
UPDATE
java.net.ConnectException is an elementary exception in network transactions. Generally standard libraries do not catch them unless there is something specific to be done.
In this case, if you are unable to catch hold of java.net.ConnectException, then you can look out to catch AxisFault thrown by org.apache.axis2.description.OutInAxisOperationClient.send.
Below snippet may be useful for you.
try {
...
} catch (RemoteException ex) {
if(ex instanceof AxisFault){
logger.error("Axis Fault error: " + ((AxisFault)ex).getFaultString());
throw new CustomExcpetion(" Custom Message ");
}
}
Also note that AxisFault is a subclass of java.rmi.RemoteException and this will not get caught when you use java.lang.Exception in a catch statement.
Shishir

MongoDB Java API com.mongodb.DBPortPool gotError

I'm currently working on a project using the MongoDB Java API. I have been working on this project for a while, but have recently come across an issue that I cannot resolve. I am trying to make a database system that is fault tolerant. To simulate a database crashing, I have my program connect to a Mongodb server that I have made, execute a simple read or write, and then shut down the database server. I had originally thought that this would cause certain methods that I am calling to throw a MongoException that I could catch and then recover from the database crash. However, I am getting a strange stack trace that says I am throwing an EOFException, among other things. Below is the stack trace itself.
Mar 04, 2013 8:06:15 PM com.mongodb.DBPortPool gotError
WARNING: emptying DBPortPool to polaris.cs.wcu.edu/152.30.5.5:12345 b/c of error
java.io.EOFException
at org.bson.io.Bits.readFully(Bits.java:48)
at org.bson.io.Bits.readFully(Bits.java:33)
at org.bson.io.Bits.readFully(Bits.java:28)
at com.mongodb.Response.<init>(Response.java:40)
at com.mongodb.DBPort.go(DBPort.java:124)
at com.mongodb.DBPort.call(DBPort.java:74)
at com.mongodb.DBTCPConnector.innerCall(DBTCPConnector.java:282)
at com.mongodb.DBTCPConnector.call(DBTCPConnector.java:256)
at com.mongodb.DBApiLayer$MyCollection.__find(DBApiLayer.java:289)
at com.mongodb.DBApiLayer$MyCollection.__find(DBApiLayer.java:274)
at com.mongodb.DBCursor._check(DBCursor.java:368)
at com.mongodb.DBCursor._hasNext(DBCursor.java:459)
at com.mongodb.DBCursor.hasNext(DBCursor.java:484)
at edu.wcu.cs.capstone.view.AbstractViewEngine.getView(AbstractViewEngine.java:57)
at edu.wcu.cs.capstone.transaction.ServerTransactionManager.getView(ServerTransactionManager.java:52)
at edu.wcu.cs.capstone.transaction.ServerTransactionManager.run(ServerTransactionManager.java:183)
at java.lang.Thread.run(Thread.java:722)
Caught exception
Mar 04, 2013 8:06:15 PM com.mongodb.DBPortPool gotError
WARNING: emptying DBPortPool to polaris.cs.wcu.edu/152.30.5.5:12345 b/c of error
java.io.IOException: couldn't connect to [polaris.cs.wcu.edu/152.30.5.5:12345] bc:java.net.ConnectException: Connec
at com.mongodb.DBPort._open(DBPort.java:214)
at com.mongodb.DBPort.go(DBPort.java:107)
at com.mongodb.DBPort.call(DBPort.java:74)
at com.mongodb.DBTCPConnector.innerCall(DBTCPConnector.java:282)
at com.mongodb.DBTCPConnector.call(DBTCPConnector.java:256)
at com.mongodb.DBApiLayer$MyCollection.__find(DBApiLayer.java:289)
at com.mongodb.DBApiLayer$MyCollection.__find(DBApiLayer.java:274)
at com.mongodb.DBCursor._check(DBCursor.java:368)
at com.mongodb.DBCursor._hasNext(DBCursor.java:459)
at com.mongodb.DBCursor.hasNext(DBCursor.java:484)
at edu.wcu.cs.capstone.view.AbstractViewEngine.getView(AbstractViewEngine.java:61)
at edu.wcu.cs.capstone.transaction.ServerTransactionManager.getView(ServerTransactionManager.java:52)
at edu.wcu.cs.capstone.transaction.ServerTransactionManager.run(ServerTransactionManager.java:183)
at java.lang.Thread.run(Thread.java:722)
DB is down.
Exception in thread "Thread-3" java.lang.NullPointerException
at edu.wcu.cs.capstone.transaction.ServerTransactionManager.run(ServerTransactionManager.java:184)
at java.lang.Thread.run(Thread.java:722)
The Caught Exception and DB is down. are print statements I am using to verify I am catching certain exceptions. Here is the relevant code:
public View getView(Mongo mongo, Query query) throws MongoException,
EOFException {
String connected = "";
try {
connected = mongo.getConnectPoint();
} catch (Exception e) {
throw new MongoException("Error.");
}
System.out.println("Connected: " + connected);
DB db = mongo.getDB(query.getServer());
List<DBObject> viewList = new ArrayList<DBObject>();
DBCollection collection = db.getCollection(query.getCollection());
DBCursor cursor = collection.find(query.getQuery(), excludeID);
try {
cursor.hasNext();
} catch (Exception e) {
System.out.println("Caught exception");
}
while (cursor.hasNext()) {
viewList.add(cursor.next());
}
return new View(viewList);
}
As you can see, the error is occurring when I call cursor.hasNext(). I am also actually still catching the exception that is being thrown because of the Caught exception. However, I am still getting a stack trace as if it was not being caught. I am suspicious that this has something to do with the DBPortPoolgotError() method, but I have looked at the code for this method, and cannot determine what it is actually doing or even how it is being called. (GrepCode link)
As stated above, I thought the behavior for this type of code would have been to throw a MongoException when a call on that specific Mongo object failed because the database was no longer active. Any help that anyone could provide would be greatly appreciated!

this happens due to the driver loosing connection. Here is an issue on the mongo bug tracker referring to it https://jira.mongodb.org/browse/JAVA-481

I had the same issue. It was because I restarted mongod without restart my java server (tomcat in my case). Restarting tomcat solved this issue because the mongo driver was lost

MissingResourceException when using JDBC?

I've used JDBC without any problems many times before, but for some reason on a new server I have it isn't working. The code compiles and runs fine on my main machine, and all the libraries (including the JDBC) should be compiled into a single JAR that I run.
Basic code:
try
{
Class.forName("com.mysql.jdbc.Driver");
}
catch (ClassNotFoundException e)
{
System.err.println("Cannot load driver...");
e.printStackTrace();
}
try
{
connection = DriverManager.getConnection("jdbc:mysql://localhost/dbname?user=dbuser&password=dbpass");
statement = connection.createStatement();
}
catch (SQLException e)
{
System.err.println("Cannot connect to database...");
e.printStackTrace();
}
The error:
Exception in thread "main" java.lang.ExceptionInInitializerError
at com.mysql.jdbc.Util.stackTraceToString(Util.java:355)
at com.mysql.jdbc.Util.<clinit>(Util.java:120)
at com.mysql.jdbc.NonRegisteringDriver.parseURL(NonRegisteringDriver.java:764)
at com.mysql.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:325)
at java.sql.DriverManager.getConnection(DriverManager.java:620)
at java.sql.DriverManager.getConnection(DriverManager.java:222)
at com.test.Server.<init>(Server.java:78)
at com.test.Server.main(Server.java:49)
Caused by: java.lang.RuntimeException: Can't load resource bundle due to underlying exception java.util.MissingResourceException: Can't find bundle for base name com.mysql.jdbc.LocalizedErrorMessages, locale en_GB
at com.mysql.jdbc.Messages.<clinit>(Messages.java:61)
... 8 more
Caused by: java.util.MissingResourceException: Can't find bundle for base name com.mysql.jdbc.LocalizedErrorMessages, locale en_GB
at java.util.ResourceBundle.throwMissingResourceException(ResourceBundle.java:1539)
at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1278)
at java.util.ResourceBundle.getBundle(ResourceBundle.java:733)
at com.mysql.jdbc.Messages.<clinit>(Messages.java:59)
... 8 more
I've never had this kind of error before, and Google is not being helpful at all. I've checked the database credentials, port number, etc. Would appreciate any help on solving it!

I encountered the same problem when I used Tomcat.
Here is my solution: add the JAR package mysql-connector-java:<version> to the lib package in Tomcat's (or your server's) installation path.

Replace..
connection = DriverManager.getConnection("jdbc:mysql://localhost/dbname?user=dbuser&password=dbpass");
with ..bcoz default port is 3306 for mysql.If changed give that
DriverManager.getConnection("jdbc:mysql://localhost:3306/minebench", "username", "password");
and add "mysql-connector-java-5.1.0-bin.jar".
then try it .