[chef] Re: Re: Re: Re: rewriting my tomcat LWRP, how best to group options?

[Bryan Berry < >]

E Sarge,

just as importantly, would you find the following confusing?

http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html 

I want to represent the -XX:* options like this

jvm do

  xx_opts do

     use_conc_mark_sweep_gc    true      # becomes   -XX:+UseConcMarkSweepGC  on command line

       allow_user_signal_handlers  false    #  becomes  -XX:-AllowUserSignalHandlers

       max_heap_free_ratio                70        # becomes  -XX:MaxHeapFreeRatio=70

  end

end

What do you think? does it just make things more complex or does it make it more readable?

On Mon, Apr 16, 2012 at 7:17 AM, Bryan Berry < "> > wrote:

Hey Edward,

I was mistaken, you can only have one Context element thus only 1 TOMCAT_HOME/conf/Catalina/localhost/foo.xml

I would have to aggregate the datasources into a single context file

I have a few more questions if you don't mind

Which would you prefer?

d_opts   OR   directives   ?

additional_opts     OR   extra_opts  OR   additional_properties   OR even_more_crap  ?

tks for your feedback!

On Mon, Apr 16, 2012 at 6:00 AM, Edward Sargisson < " target="_blank"> > wrote:

Hi Bryan,

I fear I'm a little confused. In Tomcat6, my understanding is that you have to have a single context for each web app. Thus, the two (or more) data sources have to be included in the same file so your comments about foo.xml don't make sense to me. What have I missed?

I prefer the xx_opts method. It's much clearer what's happening.

Agree that allowing a context template for complex configs is a nice solution.

Cheers,

Edward

On Sun, Apr 15, 2012 at 7:21 AM, Bryan Berry < " target="_blank"> > wrote:

Hey Edward,

thanks for the encouragement ;)

it wouldn't be terribly difficult to add support for multiple
datasources. At first I will only support one and I will try to get to
additional ones when i get the chance. i could add support for passing
an array to context_template

to have multiple i think it would be better to have something like
this than passing an array of hashes to  datasource

datasource "foo" do
 ...
end
# creates tomcat_home/conf/Catalina/localhost/foo.xml

datasource "bar" do
 ...
end
# creates tomcat_home/conf/Catalina/localhost/bar.xml


you could however easily add an additional datasource by templating an
additional context file in tomcat_home/conf/Catalina/localhost/


for  -XXgofaster  that would belong under the xx_opts

Of the two apis which I have presented, which do you prefer?

in regards to supporting additional functionality like jms, e-mail etc.

I think that would be best served by something like this

context_template :mix_of_stuff => "your_jms_template.erb"

and that could create tomcat_home/conf/Catalina/localhost/mix_of_stuff.xml

I haven't yet dealt w/ e-mail and jms settings so will have to think
about how best to handle those w/ an lwrp

thanks for your feedback!

On Sun, Apr 15, 2012 at 4:08 PM, Edward Sargisson < " target="_blank"> > wrote:
> Hi Bryan,
> I'm looking forward to seeing what the new cookbook looks like because I
> greatly rely on your good work!
>
> Firstly, would you be able to make the datasource take an array so that we
> can have multiples? In my setup, I use Liquibase to automatically upgrade
> the database. I use a special, slightly more privileged but not super, user
> to actually do that upgrade and thus have two datasources.
>
> As for jvm options, I would suggest surfacing most options with little
> translation (option 2 below). There are the very basic knobs to turn (which
> you've nicely surfaced) like heap size, GC, etc. However, if I want to twist
> another knob then I'm going to want to know exactly what I'm doing. i.e.
> maybe a page in the docs for Tomcat says use -XXgofaster so I'm going to
> want to know I've added -XXgofaster without having to read the cookbook.
> Having done similar things in JBoss and Websphere AS I definitely prefer to
> know what's going on.
>
> Lastly, what about context settings for JMS, email, etc. While I doubt you
> need to write them in right now it would be nice to have a spot in your
> model where they'd fit so that somebody can add it later.
>
> Cheers,
> Edward
>
>
>
> On Sun, Apr 15, 2012 at 6:46 AM, Bryan Berry < " target="_blank"> > wrote:
>>
>> I am rewriting my tomcat lwrp and here is what I have in mind, partly
>> inspired by Andrea Campi's work
>> https://github.com/andreacampi/application_java
>>
>> tomcat "liferay" do
>>   gc do
>>     min           "256m"
>>     max           "512m"
>>     max_perm_size "256m"
>>     algorithm     "UseConcMarkSweepGC"
>>   end
>>   profiling do               # JMX
>>     port            "98204"
>>     ssl             false
>>     authentication  false
>>   end
>>  datasource do
>>    driver 'org.gjt.mm.mysql.Driver'
>>    database 'name'
>>     port 5678
>>     username 'user'
>>     password 'password'
>>     max_active 1
>>     max_idle 2
>>     max_wait 3
>>   end
>>   ports dof
>>     http      8080
>>     https     8443  # defaults to nil and not used
>>     ajp       8009
>>     shutdown  8005
>>   end
>>
>> end
>>
>> Commandline JVM options that don't fit into the above api would have
>> to be crammed into an attribute like "additional_opts" or
>> node['tomcat']['additional_opts']
>>
>> the issue I have is whether to group the options to be used by java
>> virtual machine by function or by category.
>>
>> Here is a different take on the  tomcat lwrp, the uses a 'jvm' block
>> with the xx_opts and d_opts which correspond to -XX, and -D options.
>> thoughts?
>>
>> tomcat "pentaho" do
>>      path     "/opt/pentaho"
>>      version         "7"
>>      user            "pentaho"
>>      unpack_wars     true
>>      auto_deploy     true
>>      environment     { }
>>      jvm do
>>        xms           "256m"
>>        xmx           "512m"
>>        max_perm_size "256m"
>>        xx_opts       { }
>>        d_opts        { }
>>        additional_opts [    ]
>>      end
>>      datasource do
>>        driver 'org.gjt.mm.mysql.Driver'
>>        database 'name'
>>        port 5678
>>        username 'user'
>>        password 'password'
>>        max_active 1
>>        max_idle 2
>>        max_wait 3
>>      end
>>      ports do
>>        http      8080
>>        https     8443  # defaults to nil and not used
>>        ajp       8009
>>        shutdown  8005
>>      end
>>    end
>>
>> the JVM has so many bloody options that this may be the  more feasible
>> solution. also w/ the xx_opts, and d_opts I can use simpler options
>> hash like
>>
>> node['tomcat']['xx_opts'] = { 'ParallelGCThreads':'',
>> '+UseConcMarkSweepGC':'', 'CompileThreshold' : '10000' }
>> node['tomcat']['d_opts'] = { 'user.timezone': 'UTC',  'file.encoding':
>> 'UTF8'}
>>
>> would convert to -XX:ParallelGCThreads -XX:+UseConcMarkSweepGC
>> -XX:CompileThreshold=10000 -Duser.timezone=UTC -Dfile.encoding=UTF8
>
>