Determining the request path for logging [1.x]
I've got logging set up to log requests, responses, and faults to seperate log files. The problem is that I cannot reliably tell which request ties to with response or fault. Using timestamps is completely unreliable. I set it to log the thread information, but this is repeated everytime the thread services a new request so you cannot get reliable info this way either. So, my question is: what approach do you use to link a specific request to a specific repsonse/fault for logging etc. Thanks -T
Re: Determining the request path for logging [1.x]
If you're using a handler for logging, the handler in the request flow could add a correlation-id or request-id property to the MessageContext with a generated value, and include it in the log message. Similarly, the handler in the response flow could retrieve that property and include it in the response/fault log. The correlation id could be generated using java.rmi.server.UID or java.rmi.dgc.VMID depending upon the configuration of your server(s). Before doing this, check to see if Axis already has some correlation-id functionality or whether there is already a unique request-id in the MessageContext. Jeff On 3/1/06, Todd Orr [EMAIL PROTECTED] wrote: I've got logging set up to log requests, responses, and faults to seperate log files. The problem is that I cannot reliably tell which request ties to with response or fault. Using timestamps is completely unreliable. I set it to log the thread information, but this is repeated everytime the thread services a new request so you cannot get reliable info this way either. So, my question is: what approach do you use to link a specific request to a specific repsonse/fault for logging etc. Thanks -T
Re: Determining the request path for logging [1.x]
Just a small caveat: The uuid idea is a good one, however, from the uuid mini faq: http://www.asciiarmor.com/blog/default/2005/01/03/C62D35145B8464302800D42AB64B5036.txt java.rmi.server.UID only has 2^16 significant digits and makes no provision for the system clock being set backward. If you run java 5.0 you can use java.util.UUID which has 2^122 significant digits and doesn't have the system clock problems. There is also commons-id . For just logging the rmi.uid issues don't really come up but java.util.UUID in general is the better option. Axis2 places a uuid in the request header for WS-Addressing, but not in the response. Last I checked axis 1.x headers (been a while) it doesn't have a UUID. HTH, Robert http://www.braziloutsource.com/ Em Quarta 01 Março 2006 15:28, o Jeff Greif escreveu: If you're using a handler for logging, the handler in the request flow could add a correlation-id or request-id property to the MessageContext with a generated value, and include it in the log message. Similarly, the handler in the response flow could retrieve that property and include it in the response/fault log. The correlation id could be generated using java.rmi.server.UID or java.rmi.dgc.VMID depending upon the configuration of your server(s). Before doing this, check to see if Axis already has some correlation-id functionality or whether there is already a unique request-id in the MessageContext. Jeff On 3/1/06, Todd Orr [EMAIL PROTECTED] wrote: I've got logging set up to log requests, responses, and faults to seperate log files. The problem is that I cannot reliably tell which request ties to with response or fault. Using timestamps is completely unreliable. I set it to log the thread information, but this is repeated everytime the thread services a new request so you cannot get reliable info this way either. So, my question is: what approach do you use to link a specific request to a specific repsonse/fault for logging etc. Thanks -T --
Re: Determining the request path for logging [1.x]
Thanks guys. The java.util.UUID approach worked perfectly. On 3/1/06, robert [EMAIL PROTECTED] wrote: Just a small caveat: The uuid idea is a good one, however, from the uuid mini faq: http://www.asciiarmor.com/blog/default/2005/01/03/C62D35145B8464302800D42AB64B5036.txt java.rmi.server.UID only has 2^16 significant digits and makes no provision for the system clock being set backward. If you run java 5.0 you can use java.util.UUID which has 2^122 significant digits and doesn't have the system clock problems. There is also commons-id . For just logging the rmi.uid issues don't really come up but java.util.UUID in general is the better option. Axis2 places a uuid in the request header for WS-Addressing, but not in the response. Last I checked axis 1.x headers (been a while) it doesn't have a UUID. HTH, Robert http://www.braziloutsource.com/ Em Quarta 01 Março 2006 15:28, o Jeff Greif escreveu: If you're using a handler for logging, the handler in the request flow could add a correlation-id or request-id property to the MessageContext with a generated value, and include it in the log message. Similarly, the handler in the response flow could retrieve that property and include it in the response/fault log. The correlation id could be generated using java.rmi.server.UID or java.rmi.dgc.VMID depending upon the configuration of your server(s). Before doing this, check to see if Axis already has some correlation-id functionality or whether there is already a unique request-id in the MessageContext. Jeff On 3/1/06, Todd Orr [EMAIL PROTECTED] wrote: I've got logging set up to log requests, responses, and faults to seperate log files. The problem is that I cannot reliably tell which request ties to with response or fault. Using timestamps is completely unreliable. I set it to log the thread information, but this is repeated everytime the thread services a new request so you cannot get reliable info this way either. So, my question is: what approach do you use to link a specific request to a specific repsonse/fault for logging etc. Thanks -T --
