Bug 417834 - Improve ValueAdd to provide "on-demand" logs
Summary: Improve ValueAdd to provide "on-demand" logs
Status: NEW
Alias: None
Product: TCF
Classification: Tools
Component: Core (show other bugs)
Version: unspecified   Edit
Hardware: PC Linux
: P3 major (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact: Eugene Tarassov CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-09-23 10:39 EDT by xavier pouyollon CLA
Modified: 2013-10-01 03:31 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description xavier pouyollon CLA 2013-09-23 10:39:24 EDT
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.
Comment 1 xavier pouyollon CLA 2013-09-25 08:46:13 EDT
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).
Comment 2 Felix Burton CLA 2013-09-25 14:55:58 EDT
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.
Comment 3 xavier pouyollon CLA 2013-09-30 09:07:51 EDT
> 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 !
Comment 4 Felix Burton CLA 2013-09-30 19:36:48 EDT
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.
Comment 5 xavier pouyollon CLA 2013-10-01 03:31:15 EDT
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.