Community
Participate
Working Groups
Using the following setup: Client <----> ValueAdd <-----> Target when a problem occurs, we usually end-up doing: Client <--> Logger 1 <---> ValueAdd <---> Logger 2 <---> Target. We'd like to be able to do that "on-demand". This would avoid: - Breaking the current connection - Minimize the amount of log. We'd like to trigger this through a TCF Service. We believe this could help a lot when the product will be used "on-site". Moreover, it would by nice also to be able to trigger "on-demand" the ValueAdd traces. I have no idea of the complexity to achieve this. Comments welcome. Thanks.
To be more specific. Our proprietary ValueAdd (aka tcf-server) does intercept some events. On these events, it will sends some queries to the target. We'd like a simple way to log this TCF traffic. We'd like to avoid doing: ValueAdd <----> TCF Logger <----> Target. Why ? Because if we already have an established connection: ValueAdd <----> Target, we need to close it / reopen it with the additionnal loggers in the chain. Launching the ValueAdd with -ltcflog is not enough : It will only display TCF Traffic that is "proxyed" (the way I understand it : It will just log all the TCF content that is not "intercepted" / "generated" by the ValueAdd. In other words: It will NOT log the TCF commands sent by the ValueAdd itself, for instance to synchronize the list of children at redirect). We'd like another option to be able to log the TCF traffic received / sent by the ValueAdd itself. Looking at the way the logging is done, it seems not direct at all because log is done at "proxy" level. Any suggestions, ideas welcome. May be our approach is wrong too ? The idea is to be able to trigger the logs "on-demand" in order to minimize logs size (just enable it before thing go wrong in a lengthy debug session for instance).
One way to do this without creating a separate log process is to intercept the read/write functions for the channel in your value-add process. Once the channel is connected it should be possible to save and replace the function pointers c->inp.read, c->out.write, c->out.write_buf, and c->out.splice_block with you own version that logs the data and calls the saved functions to do the actual read/write.
> it should be possible to save and replace the function pointers c->inp.read, c->out.write, c->out.write_buf, and c->out.splice_block with you own version that logs the data and calls the saved functions to do the actual read/write I've done that in the ValueAdd when we redirect to our target. Unfortunately, only c->out.write is being called and parameter byte is only 0 or -1. (And it is not called for all characters send). Here is my routine: static void log_target_write (OutputStream * stream, int byte) { fprintf (stderr, "in log_target_write %d\n", byte); if (isprint(byte)) fprintf (stderr, "%c", (char) byte); saved_write(stream, byte); ==> tcp_write_stream is the saved function. return; } The various routines (write_stringz and other) do fill a buffer. Seems I need to put my hooks in these routines instead and can't use your proposal, unless I'm missing something (Unfortunately, there is no pointer in the OutputStream to the Channel / TCP_Channel to dump the buffer) ? Thanks !
You are right, the current implementation makes it not possible to intercept these functions and guarantee that all bytes are logged. Other alternatives are to 1) create a wrapper for the channel object, or 2) add a channel API to add/remove trace listeners. I am not sure which approach is best or what kind of issues there will be without trying it.
Thanks Felix. After speaking with Didier, we came to the following conclusion: - OnDemand log is risky : We might miss some important definitions from the log making it very hard to interpret. We need a full log. - Reducing the size of the log : We'll add a LOCATER peer.. filter in the logger. - Reducing the size of the log : If needed, we might add zlib to zip the log in streaming mode. - The ValueAdd will have an option to spawn a TCF Logger when a redirect command is issued making it easier to setup.