dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

Hi

2009/3/31 Lars Helge Øverland <larshelge@xxxxxxxxx>:
>
>>
>> > Sorry obviously that won't be enough. DHIS 2 looks for config file in
>> > this
>> > order: 1) default properties file in dhis-support-hibernate 2) Classpath
>> > in
>> > the WAR 3) DHIS2_HOME env variable, where the last one gets precedence.
>> > We
>> > could read in a hibernate.properties file and overwrite a file on the
>> > classpath inside the WAR. But that won't be extremely elegant.
>> > Alternatively
>> > we could modify DHIS 2 to look for a system property dhis2.home and use
>> > the
>> > get/setProperty methods.
>> >
>>
>> I think a system property (eg dhis2.home) is an excellent idea - much
>> prefer them to environment variables.  It might also provide some
>> flexibility for those who are deploying multiple dhis2 applications on
>> a single server machine as we saw in India. I'm pretty sure we could
>> then put the properties file in the jar though it seems reasonable to
>> have the configurable bits outside and easily editable. Though a mixed
>> blessing I know ...
>
> OK. I think we need to keep the environment variable in addition since
>
> - system properties are Java-specific and I guess the only way to set it
> outside Java is through -D options to the java command line (?) for use with
> standard databases.
> - we would have to update all existing installations if we remove it...
>
>>
>> I wonder if we might make a slight improvement to startup time while
>> we're at it.  Currently it seems the DHIS hibernate sub-system looks
>> for all those locations before finally deciding to use the latter.
>> Can we do the search in the reverse order - ie if dhis2.home property
>> is set, check for hibernate.properties, use that and get straight on
>> with the rest of the busy tasks of initialisation.  On my system that
>> will shave off 2 or 3 seconds.
>>
>
> A problem with this is that it's handy to have the files overriding each
> other as the default properties contains more information than what the
> "DHIS2_HOME one" usually does, like connection pooling and caching. But we
> could say that if the DHIS2 system property is set, we could skip looking
> for the DHIS2 environment variable?
>
> System.getProperty( "user.dir" ) will give you the current working
> directory.

OK.  That works!  I'm currently still using DHIS2_HOME for finding
hibernate.properties, but I have:
System.setProperty("dhis2.home", System.getProperty("user.dir"));
in the startup code, so the env variable is there for when you can use it.

> So we have a hibernate.properties in or inline with the exe jar which looks
> up its cwr, sets a dhis2.home system property with this value, starts the
> webapp and lets dhis2 read it in...?
>

I've finally got rid of all the pesky System.err.println() statements
and am using Jetty's Log class.  Haven't figured out yet how to tie it
in with the commons logging in the webapp and log to a file (other
than stderr).  That's the next challenge ... priority 1.

However it does give me the chance to make some observations on
startup time (with an empty database).  Total startup time on my XP
virtual machine is 35s.  I'm going to put XP on my little asus for a
realistic low power scenario and will measure again.  But particularly
for dhis2-lite it would be good to reduce this.

1. Of this, 10s is being used to unpack the war.
2..About 10s being used since finding final hibernate.properties and
starting startup routine 1
3. About 5 seconds doing startup routine 1
4. About 5 seconds initialising Spring

If we are going to slim down the startup time this is where we should
look.  Not much can be done about 4.  About 1 I think it will be a
huge improvement (30%) to deploy the exploded war and not let jetty
make a temporary copy.  The only benefit of having it do its default
behaviour is to allow for hot (re)deployment which is not a concern
here.  I'll work on persuading jetty to oblige.  priority 2.

I'm not sure what is going on at 2 yet.    Probably not much can be
done about the startup routines either.

I'll aim for a 20-25s startup.  Already we are an improvement with no
mysql to start and a much lighter baby-jetty to start than fully
fledged tomcat.  And having some visual feedback of the status of the
app on starting up is already useful.  Can make this even more user
friendly in time.

Cheers
Bob