0

Im sorry about the title but I'm not sure hw else to describe the issue. I have a SingletonBean with a class that extends TimerTask. The point is that when the application is launched it starts running some a set of scheduled background tasks on a loop. Everything works fine at first glance, the Timer() executes the run() method and the scheduled job gets executed perfectly every 120 secs.

Inside the run() I have a method that gets a list of information from a AWS DynamoDB. 

List<SiteObj> sites = storedDynamoQueries.scanSite("uid");

Again this works perfectly, and as expected in my ide I can place a break on that method and it pauses every 120 secs when it executes waiting for me to step over it.

Now for the problem! As mentioned above the Timer is set to execute every 120 secs. However every 120 secs but OFFSET by 60 secs. I get an error as follows:

SEVERE: Error wih Dynamo Site Scan
java.lang.NullPointerException
    at org.apache.log4j.LogManager.getLogger(LogManager.java:179)
    at org.apache.log4j.Logger.getLogger(Logger.java:94)
    at org.apache.commons.logging.impl.Log4JLogger.getLogger(Log4JLogger.java:289)
    at org.apache.commons.logging.impl.Log4JLogger.debug(Log4JLogger.java:177)
    at com.amazonaws.auth.AWS4Signer.sign(AWS4Signer.java:119)
    at com.amazonaws.http.AmazonHttpClient.executeHelper(AmazonHttpClient.java:239)
    at com.amazonaws.http.AmazonHttpClient.execute(AmazonHttpClient.java:165)
    at com.amazonaws.services.dynamodb.AmazonDynamoDBClient.invoke(AmazonDynamoDBClient.java:985)
    at com.amazonaws.services.dynamodb.AmazonDynamoDBClient.scan(AmazonDynamoDBClient.java:560)
    at com.amazonaws.services.dynamodb.datamodeling.DynamoDBMapper.scan(DynamoDBMapper.java:1066)
    at com.amazonaws.services.dynamodb.datamodeling.DynamoDBMapper.scan(DynamoDBMapper.java:1028)
    at tv.tarka.dastraxweb.integration.dynamo.StoredDynamoQueries.scanSite(StoredDynamoQueries.java:1584)
    at tv.tarka.dastraxweb.application.snmp.Scheduler$ScheduledTask.run(Scheduler.java:72)
    at java.util.TimerThread.mainLoop(Timer.java:555)
    at java.util.TimerThread.run(Timer.java:505)

Now this is an error triggered by the same method as described above. But When I try to debug it the system is saying that the class is not even being called! It doesn't appear in the debugger, and it shouldn't be being called by all accounts especially not offset by 60 secs from the rest of the run().

Anyway I suspect the answer has something to do with the last two lines of the trace.

at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)

But I have no idea what might be causing this.

Kiril
  • 39,672
  • 31
  • 167
  • 226
tarka
  • 5,289
  • 10
  • 51
  • 75
  • check your log4j.xml . Side suggestion use `Executors.newScheduledThreadPool` instead of Timers and TimerThreads – Ajay George Dec 17 '12 at 15:17

2 Answers2

1

This means logging library cannot acquire a logger. Check logger configs.

Dims
  • 47,675
  • 117
  • 331
  • 600
0

It looks like there are either conflicting logging framework implementation classes or a missing commons-logging.properties file. Although you can mix calls to the log4j, log4j 2, slf4j, commons-logging, etc. API's, the classes that you include in the dependencies have to be compatible. There is a set of classes that uses log4j as the set of implementation classes and there is another set of classes that uses log4j 2 as the implementation classes at the bottom.

See https://bradleyaross.wordpress.com/2016/05/05/java-logging-frameworks/

If you look at the tutorials-log4j1 and tutorials-log4j2 modules in the project at http://www.github.com/bradleyross/tutorials, you will see examples of the set up for each class.

If using the log4j 1.x implementation classes, you will need a log4j.xml file, a commons-logging.properties file indicating that the messages are sent to log4j or the appropriate system and the jar files are commons-logging-1.2.jar log4j-1.2.17.jar log4j-to-slf4j-2.0-beta4.jar

If using the log4j 2 implementation files, I used log4j2.xml and commons-logging-1.2.jar log4j-1.2-api-2.5.jar log4j-api-2.5.jar log4j-core-2.5.jar log4j-slf4j-impl-2.5.jar (This eliminates the need for commons-logging.properties)

See http://docs.aws.amazon.com/AWSSdkDocsJava/latest/DeveloperGuide/java-dg-logging.html

The only jar file common to both sets is commons-logging-1.2.jar. Mixing any of the other files from the two sets will cause massive problems. (As my old manuals from IBM used to say, the results are undefined.)

log4j 1.x is no longer supported

Bradley Ross
  • 445
  • 2
  • 8