aws-lambda-java-libs: log4j2: AWSRequestId set in ThreadContext map, incorrect for multithreaded applications
If I include a %X in my pattern layout, I see that the following appears in my log output
... { AWSRequestId=4e145840-092b-11e8-a601-a9957c1b507d}...
I don’t see anything in this library that sets ThreadContext, so I am unsure if this is somehow being set by the Lambda runtime or by some other log4j2 mechanism I am not aware of.
While this value appears to be correct in the main thread, I have noticed that other threads such as in a fork join pool will have this value populated, but often incorrectly (in the case of container re-use, it will retain the value of a previous invocation/request Id). Usually some of the threads have correct IDs while others have stale/old/incorrect IDs: I think the behavior is the request ID is set once the first time the thread is used in a container, but after the thread has been spawned the request ID in the child threads never get updated again, so they retain the request ID of whatever invocation was the first to use/spawn that particular thread.
What library/entity owns setting this request ID and how can I get this to be correct for multi-threaded applications?
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 17 (1 by maintainers)
That probably wouldn’t be too hard, sure.
Sorry @jhovell my mistake, I thought you’d happily resolved this yourself. Yes if you would like to submit a PR we’d be more than happy to look at it.
I’m having the same problem. It’s really helpful to use the lambda request ID to filter in Cloudwatch Logs to view all the logs from a single request. However, we use multi-threading in our lambda functions as well. Because %X{AWSRequestId} does not get substituted properly in child thread log entries, we can’t find all the relevant log information.
It would be great if @jhovell could put up a pull request for his solution or someone from AWS could address this.