Hi,

On Thu, Jan 26, 2012 at 3:30 PM, KasunG Gajasinghe <[email protected]> wrote:

> This is the notes for architecture and code of the new component, carbon
> bootup validator held on 26th Jan 2011. Please amend it as necessary.
> Relevant JIRA - https://wso2.org/jira/browse/CARBONROADMAP-15
>
> In the current arch, only the hard-coded parameters can be checked.
> Parameters should be broken down to validators for extensibility. The
> parameters here refers to heapMemory etc. See
> https://wso2.org/jira/secure/attachment/18252/config_validation.xml
>

Why we need both RAM and freeRAM validation? Can't we have only freeRAM
validation? (same question apply to Swap as well)

Thanks.


> The point is, for a given validator, create a hashmap for the parameters
> name-value pair, and pass it to the validator. So, there will be a HashMap
> per Validator. Inside a validator retrieve the current system hardware and
> system properties, and compare the values. This new arch invalidates the
> need of separate DataCollectors. Data collecting is also done inside a
> validator.
>
> Then, the interface for validators will look like -
> protected init (Map recommendedValues),
> protected abstract Map<String, ValidationResult> validate(),
>     - No printing inside the validators. This isnt the presentation layer.
>     - just validate the parameters and return true/false
>     - The guy using these values can decide what to do
>
> The stubs of how the invocation happen (like Azeez's 'How to make a tea'
> example ;) ) will be like what's in the provided snapshot.
>
>
> Apart from the above architectural decisions, following decisions were
> taken.
>
>    - Rename the config file config_validation.xml to
>    config-validation.xml. Separating words by dash (-) is the general standard
>    for carbon and axis2.
>    - Concerns raised whether the measurement unit (like MBs, MHz) should
>    be added as a parameter instead of a comment for configurability. But
>    agreed that it's OK for the moment.
>    -
>    - Add a new Validator for validating System Properties. Some use cases
>    - If an user removes a sh script, there can be problems at runtime, sys
>    properties like carbon.home should be available.
>    - Add an optional validator for validating GC optimization parameters.
>    Add a commented xml such that end-user can uncomment if needed.
>    - Add PermGen size as well to the JVMValidator.
>    - Display a message stating the tested OSes if the OS at runtime
>    hasn't been tested.
>
>
> Code level notes -
>
>    - Catching exceptions ---    Properly handle and throw the exceptions.
>    Rename ConfigurationParamaeterException to something like
>    UnrecongnizedParameterException, and make it a RuntimeException because
>    this isnt about business logic
>    - Make 'activate' variable in ConfigValidationXMLProcessor class final
>    - Create Logger instance per class, not per instance. Such that make
>    it private static final.
>    - Remove the construct in ConfigValidationXMLProcessor
>    - Have interfaces (like List, Map etc.) for reference class instead of
>    having ArrayList, HashMap etc.
>
>
>    - Use ulimit -n for max number of opened files. It includes the opened
>    socket count as well. SystemDataCollector class
>
>
> Regards,
> --KasunG
>
>
> --
> *Kasun Gajasinghe*
> Software Engineer; WSO2 Inc.; http://wso2.com
>
> ,
> *email: **kasung AT spamfree wso2.com** cell: **+94 (77) 678-0813*
> *blog: **http://blog.kasunbg.org* <http://blog.kasunbg.org>
>
> *
> twitter: **http://twitter.com/kasunbg* <http://twitter.com/kasunbg>
>
> *
> *
>
>
> _______________________________________________
> Carbon-dev mailing list
> [email protected]
> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
>
>


-- 

regards,
Nirmal

Software Engineer, WSO2 Inc.
mobile: +94715779733
_______________________________________________
Carbon-dev mailing list
[email protected]
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev

Reply via email to