SDK for Java Calls

The SDK for Java Calls comes with Apache Commons Logging, which is a layer of abstraction, that enables the user to use as many logging systems as he sees fit. It is utilized for logging SDK for Java Calls.

SDK for Java - Log4j and Java

SDK for Java – Log4j and Java

The allowed logging systems include the Java Logging Framework and Apache Log4j and other logging systems. The remainder of this post shows you how to use Log4j. While using the SDK’s logging functionality you do not need to change your software’s code.

Keep  in Mind

This post talks about Log4j 1.x., since, Log4j2 doesn’t support Apache Commons Logging. However, it provides an adapter that automatically directs the call logging function to Log4j2 using the Apache Commons Logging interface.

 

Download the Log4J JAR to work with SDK for Java Calls:

In order to use Log4j with the SDK,  a download of log4j JAR needs to be made. The download can be found at the official Apache website. The SDK does not include the JAR file by default. After downloading the jar file you need to manually place it to a location in your classpath.

log4j.properties is the configuration file for log4j.

SDK for Java Calls - log4j.properties

SDK for Java Calls – log4j.properties

Example configuration files are shown below. Place the below examples of a configuration file in a directory on your classpath. The Log4j JAR and the log4j.properties file do not need to be in the same directory to work.

SDK for Java Calls - Properties and JAR Files Directories

SDK for Java Calls – Properties and JAR Files Directories

The “log4j.properties” configuration file consists of properties. One property example is logging level, where logging output is sent either to a file or to the console, and the format of the output is to be specified. The logging level is the level of detail of the output that the logger generates. The concept of Multiple logging hierarchy can be used by Log4j. The logging level is set for each hierarchy separately without affecting other hierarchies.

The 2 logging hierarchies below are supported by the AWS SDK for Java:

  • log4j.logger.com.amazonaws
  • log4j.logger.org.apache.http.wire

 

Setting the Classpath to use when working with SDK for Java Calls:

the Log4j JAR and the log4j.properties file need to be located in your classpath together. If you decide to use Apache Ant, you have to set the classpath in the path element inside your Ant file. The example below portrays a path element from the Ant file for the Amazon S3 example included with the SDK.

<path id=”aws.java.sdk.classpath”>

<fileset dir=”../../third-party” includes=”**/*.jar”/>

<fileset dir=”../../lib” includes=”**/*.jar”/>

<pathelement location=”.”/>

</path>

If you prefer using Eclipse IDE, you could set the classpath by opening the menu and going to Project | Properties | Java Build Path.

SDK for Java Calls - Java Build Path

SDK for Java Calls – Java Build Path

Mistakes and Warnings that are Service-Specific with SDK for Java Calls:

We recommend that you keep the “com.amazonaws” logger hierarchy set as “WARN” in order to catch any important messages from the client libraries. For example, if the Amazon S3 client detects that the InputStream inside your application hasn’t properly closed and could cause the leaking of resources, the S3 client reports it through a warning message which would appear in the logs. This makes sure that the messages are logged if the client is experiencing issues while attempting to handle requests or responses

The log4j.properties file portrayed below sets the rootLogger to WARN, which allows warning and error message from all loggers in “com.amazonaws” hierarchy to be included. Alternatively, you can always explicitly set the com.amazonaws logger to WARN.

log4j.rootLogger=WARN, A1

log4j.appender.A1=org.apache.log4j.ConsoleAppender

log4j.appender.A1.layout=org.apache.log4j.PatternLayout

log4j.appender.A1.layout.ConversionPattern=%d [%t] %-5p %c –  %m%n

# Or you can explicitly enable WARN and ERROR messages for the AWS Java clients

log4j.logger.com.amazonaws=WARN

 

Logging the Summary for Request/Response:

All requests to a service create a unique request ID which can be handy if you run into a problem generated from how a service is handling a request. Request IDs are accessible through Exception objects in the SDK after any failed service call, they can also be reported through the DEBUG log level in the “com.amazonaws.request” logger.

The below log4j.properties file allows for a summary of requests and responses, which includes request IDs.

In some cases, it can be handy to monitor the exact requests and responses that the AWS SDK for Java is sending and receiving. Since large requests, like a file being uploaded to S3, or responses can throttle an application this logging should not be enabled in production systems. If you for whatever reason need this information you can use it temporarily by enabling it through the “Apache HttpClient 4 logger” and then disabling it when you are done. Enabling the DEBUG level on the apache.http.wire logger allows logging for all request and response data.

The following log4j.properties file toggles on full wire logging in Apache HttpClient 4 and should only be turned on temporarily because it can significantly impact the performance of your application.

log4j.rootLogger=WARN, A1

log4j.appender.A1=org.apache.log4j.ConsoleAppender

log4j.appender.A1.layout=org.apache.log4j.PatternLayout

log4j.appender.A1.layout.ConversionPattern=%d [%t] %-5p %c –  %m%n

# Log every HTTP content  for

# each request and response. Be careful when working with this because it may

# be quite costing for logging that much verbose data!

log4j.logger.org.apache.http.wire=DEBUG

 

Logging for Latency Metrics when working with SDK for Java Calls:

If you want to see metrics while troubleshooting, an example of a metric would be which process is taking the longest time or whether the server or the client side has the greater latency. The latency logger in this case will come in handy. Set the com.amazonaws.latency logger to DEBUG to turn this logger on. To learn more about metrcis you check the AWS SDK Metrics guidlines.

Keep in Mind

Such a logger may be available when SDK metrics gets enabled.

log4j.rootLogger=WARN, A1

log4j.appender.A1=org.apache.log4j.ConsoleAppender

log4j.appender.A1.layout=org.apache.log4j.PatternLayout

log4j.appender.A1.layout.ConversionPattern=%d [%t] %-5p %c –  %m%n

log4j.logger.com.amazonaws.latency=DEBUG

Here you can see a log output example.

com.amazonaws.latency – ServiceName=[Amazon S3], StatusCode=[200],

ServiceEndpoint=[https://list-objects-integ-test-test.s3.amazonaws.com],

RequestType=[ListObjectsV2Request], AWSRequestID=[REQUESTID], HttpClientPoolPendingCount=0,

RetryCapacityConsumed=0, HttpClientPoolAvailableCount=0, RequestCount=1,

HttpClientPoolLeasedCount=0, ResponseProcessingTime=[52.154], ClientExecuteTime=[487.041],

HttpClientSendRequestTime=[192.931], HttpRequestTime=[431.652], RequestSigningTime=[0.357],

CredentialsRequestTime=[0.011, 0.001], HttpClientReceiveResponseTime=[146.272]

AWS sdk metrics


AUTHOR