Re: [Vrs-development] Testing

[Chris Smith]

Well this is cool.
And as Goldwater is the layer onto which we're building the application this 
is all sorted out for you (ie the multi LDS on a single machine).

You can boot multiple seperate instances of Goldwater on a single machine and 
have them communicate as though they were distibuted across several machines 
(the point being that the application layer has no concept of the network, 
which is why this works).

Also each Goldwater application has it's own logging facility, fully 
timestamped of course.  Programs log out to one of more categories, and the 
logging level may be switched dynamically to stop rather verbose items being 
logged, or to turn certain log event on when required.

For instance, an application may write a log entry against one or more of the
followint 'types':
Audit
SQL
Debug
Flow
Data
Control
Error
Serious Error
(there are more I think....)

and you can enable which 'types' are currently enabled and outputting to the 
log.

The log entries are marked with the 'type' the entry was written against, so 
a grep can grab what you want.

The gw_log function will need to be integrated with portableNet via pInvoke, 
but it's an excellent logging system, plus all the logs will be together.

Log example attached.


On Wednesday 14 August 2002 00:31, you wrote:
> vrs developers,
>
> i'm been thinking about vrs and designing the rm and i've realized
> something. it is very important to have a structured way to test. since vrs
> is going to be a very long and complicated project consisting of many
> separate subprojects, we need a uniformed way to test each other's code. i
> will describe what i think we should have for a testing environment.
>
> i envision a testing framework/simulator (whatever you want to it) that
> let's us run multiple instances of lds's. the tester has an option of using
> the network (a port for each lds) or not using the network. when the tester
> is not using the network, messages sent to the network will be passed to
> the appropriate lds node. the tester will encapsulate each instance of a
> lds node and monitor messages passed between them. aside from monitoring
> inter-vrs messages, there should also be a mechanism to log activities
> happening internally. now i'm not thinking about something crazy that
> monitors the actual execution in memory. instead, it will just read logging
> information the actual classes produce and display them on the tester. so
> say there is some sort of configuration file. so let's say i make my
> config.xml. the tester creates 5 lds nodes then does some file transfers
> and installs an eod, all specified by config.xml. then the execution would
> produce logs that showed the flow of execution. the trick is to timestamp
> each log and display them in the order that they would most likely occur
> in. that is the reason that this tester should be both a testing framework
> and a simulator. network latency and other properties (available bandwidth,
> node failures, etc) should be configurable to test the system in different
> settings. in this respect it is a simulator. the tester also supports a
> testing framework where test cases can be created and the results
> interrupted in a user-friendly way.
>
> well that's what i'm thinking about. let me know what you think. regardless
> of what you think the tester should do, i believe we need something to ease
> the pain of distributed testing.
>
> -alias
>
>
>
> _______________________________________________
> Vrs-development mailing list
> address@hidden
> http://mail.freesoftware.fsf.org/mailman/listinfo/vrs-development

-- 
Chris Smith
  Technical Architect - netFluid Technology Ltd.
  "Internet Technologies, Distributed Systems and Tuxedo Consultancy"
  E: address@hidden  W: http://www.nfluid.co.uk

log.log
Description: example goldwater log