I am sniffing around the edges of asadmin's multimode capability (where you
(for example) pass a file of asadmin subcommands and have them all
executed).

There is no facility for if/then tests--I get that; multimode is not a
scripting language.

So is there defined behavior for what happens when a command in the
multimode file fails? Does execution bomb out or keep going? I can (and
will) obviously try this but wanted to know what steps were taken (and
specified) in multimode processing to handle errors.

(I'm hoping that whatever specification is behind multimode processing
indicates that execution just keeps on marching and does not bomb out.)

It's been my experience that it reports the issue and keeps on chugging to the next cmd in the file. I haven't tried every cmd via multimode, mostly JVM option settings, resource adds, network and das configs etc.

If you need something hearty your best bet would probably be to have a ReST client read in a cmd file and use the ReST admin interface. Then you could have more fine grain control on the results of each cmd.

-Noah

-Noah

On Jan 9, 2013, at 1:16 PM, Laird Nelson wrote:

> I am sniffing around the edges of asadmin's multimode capability (where you (for example) pass a file of asadmin subcommands and have them all executed).
>
> There is no facility for if/then tests--I get that; multimode is not a scripting language.
>
> So is there defined behavior for what happens when a command in the multimode file fails? Does execution bomb out or keep going? I can (and will) obviously try this but wanted to know what steps were taken (and specified) in multimode processing to handle errors.
>
> (I'm hoping that whatever specification is behind multimode processing indicates that execution just keeps on marching and does not bomb out.)
>
> Best,
> Laird
>
> --
> http://about.me/lairdnelson

> If you need something hearty your best bet would probably be to have a
> ReST client read in a cmd file and use the ReST admin interface. Then you
> could have more fine grain control on the results of each cmd.
>

That's a good point; thanks. (I'm just looking to automate in this case
the creation of JVM options--unfortunately you have to know if they're
present and what their value is to change them. For example, you can't
just say: "please replace whatever max memory setting is already specified
with -Xmx1024m", you have to say "delete -Xmx512m" and then "add
-Xmx1024m". If instead what's present is (say) -Xmx256m, then just by
using multimode you'll have two JVM memory options set.)

On 1/9/13 10:32 AM, Laird Nelson wrote:
> On Wed, Jan 9, 2013 at 10:24 AM, Noah White > wrote:
>
> If you need something hearty your best bet would probably be to
> have a ReST client read in a cmd file and use the ReST admin
> interface. Then you could have more fine grain control on the
> results of each cmd.
>
>
> That's a good point; thanks. (I'm just looking to automate in this
> case the creation of JVM options--unfortunately you have to know if
> they're present and what their value is to change them. For example,
> you can't just say: "please replace whatever max memory setting is
> already specified with -Xmx1024m", you have to say "delete -Xmx512m"
> and then "add -Xmx1024m". If instead what's present is (say)
> -Xmx256m, then just by using multimode you'll have two JVM memory
> options set.)
That's terrible! Can you file an issue on -Xmx handling?
>
> Best,
> Laird
>
> --
> http://about.me/lairdnelson

Sure. To be fair, I'm not sure entirely that distinguishing between JVM
options ("This one is special, so we'll ignore its value, and that one
isn't, so we'll use its value") is the right thing to do either.

In any event I'll file the issue and describe it and we'll go from there.