On Thu, Jan 26, 2012 at 3:36 PM, Nirmal Fernando <nir...@wso2.com> wrote:

> Hi,
>
> On Thu, Jan 26, 2012 at 3:30 PM, KasunG Gajasinghe <kas...@wso2.com>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)
>

Free RAM can be tricky; we can only obtain a instancial value of it as it
changes over the time. Also there can be cases like hosting multiple
servers on the same hardware.

Anyway, nowadays all the OSs have their implemntation of
*optimized*virtual memory. Therefore given that you have enough
physical memory,
 performance is good. i.e. no use of having very very large physical memory
for most of well engineered codes (like the stuffs we have :)  )  given
that you have sufficiently large physical memory.

Therefore I guess just checking RAM is what we'll need.

Thanks,
 - Chethiya

>
> 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
>> Carbon-dev@wso2.org
>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
>>
>>
>
>
> --
>
> regards,
> Nirmal
>
> Software Engineer, WSO2 Inc.
> mobile: +94715779733
>
>
> _______________________________________________
> Carbon-dev mailing list
> Carbon-dev@wso2.org
> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
>
>


-- 
Chethiya Abeysinghe
Software Engineer; WSO2, Inc.;  http://wso2.com/
email: cheth...@wso2.com     phone: +94 777334874
blog: chethiya3000.blogspot.com
_______________________________________________
Carbon-dev mailing list
Carbon-dev@wso2.org
http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev

Reply via email to