Tracing requests to through the Access Gateway/ Secure Proxy Server to determine the cause of delays, requires us to have a good handle on the request as we trace it from the client browser :
A request from the client browser:
Through the Ag server to the backend.
The trace of the data sent and received between SPS -> backend server is logged in httpclient.log and the log4j formatting looks like this :
That format make it difficult (virtually impossible) to identify which response from the backend sever is tied to an which sent request.
The new format :
Allows us to tie, via the threadid the request ">>" with its' response data "<<" received from the backend.
The advantages of this log4j format are:
a) It shows PID & threadId for each log line 
Currently it is not possible in httpclient log to identify the response to an individual request.
with the threadid it is possible to tie the request sent to the backend with ">>" tag and the response from the
backend with "<<" tag as they will have the same threadid.
b) It shows SrcFile line of code Wire.java:63
Not as useful, in this case, but in other log4j circumstances can identify the line of code responsible for
writing the log file entry
c) MS timeframe
Most transactions occur in ms timeframe so this is better default
d) Data is all one one line
Having the data all on one line makes it simpler to use tools like grep and find since they then have the complete log record, not just half of it.
Doing extra work takes time, threadid is not a lot of work, log4j dont guarantee the threaid is the samebut in all my test cases it has been the same (if you have some remote logger for example the threadid may be different).
SrcFile does add a bit of overhead (which is why they dont normally do it) - but can be useful - if you dont need it and speed is important you can comment it out in the code.
I didn't work really hard on making the formatting efficient - so that could probably be improved if speed is needed in my case this is used for those odd occasions where there is some delay in the backend and we need to identify which transactions have the delay.