[Fwd: Re: Fwd: [jboss-dev] Project ByteMan]

Tue Jun 23 07:33:58 EDT 2009

Sorry replied to the forward before I saw the post on jboss-dev

-------- Original Message --------
Subject: Re: Fwd: [jboss-dev] Project ByteMan
Date: Tue, 23 Jun 2009 12:29:13 +0100
From: Andrew Dinn <adinn at redhat.com>
To: Kabir Khan <kabir.khan at jboss.com>

Hi Kabir,

I am in the middle of setting up the byteman project at the moment
(Jazoon talk tomorrow, so plenty of tie yet ;-). There should be a
project page at jboss.org/byteman by the end of today and a forum plus
JIRA very soon.

If you want to obtain the latest release then you can check it out from
the current temporary svn home at

http://anonsvn.jboss.org/repos/labs/labs/jbosstm/workspace/adinn/byteman/downloads/1.0.1/

There is a binary zip containing the byteman jar and README/user guide
and a zip containing the full sources and test code.

regards,

Andrew Dinn
-----------

On 06/22/2009 07:00 PM, Kabir Khan wrote:
> dev list seems broken
>
> Begin forwarded message:
>
>> From: Kabir Khan <kabir.khan at jboss.com>
>> Date: 22 June 2009 18:19:00 BST
>> To: "JBoss.org development list" <jboss-development at lists.jboss.org>
>> Subject: Re: [jboss-dev] Project ByteMan
>>
>> Is ByteMan in the maven repository somewhere? I'd like to try it out
>> to test parallel deployments in MC
>> On 11 Jun 2009, at 15:08, Andrew Dinn wrote:
>>
>>> Galder Zamarreno wrote:
>>>> Andrew, did you get around to compare ByteMan with JBoss AOP?
>>>
>>> Yes, I had a closer look at AOP.
>>>
>>>> IMO, both seem to do the same, instrument classes to add some
>>>> behaviour here or there. ByteMan simply seems to use load time
>>>> weaving style whereas JBoss AOP had two modes.
>>>
>>> Yes, I think you can use AOP to inject code in all the same places that
>>> ByteMan can inject code. ByteMan does make local variables available
>>> for use in the injected code which I don't think AOP can do but
>>> that's not the most important feature of either.
>>>
>>>> So, why should I use ByteMan over JBoss AOP if JBoss AOP is already
>>>> integrated with AS? Easy of use? Memory consumption? Speed?
>>>> Functionality?
>>>
>>> Well, firstly, when it comes to testing via fault injection ByteMan
>>> is a lot simpler and easier to use than AOP not that I am thereby
>>> knocking AOP). You don't have to define any classes or compile any
>>> code in order to use Byteman. The injected side effects can simply be
>>> written into the rule script as Java code or built-in helper method
>>> calls. Mostly when you are testing code you want to tweak the current
>>> behaviour and that doesn't normally need you to write a lot of code.
>>> Usually, most of the behaviour you need to change is either simple to
>>> script using a few basic Java operations and/or the public API of the
>>> classes you are testing.
>>>
>>> However, sometimes the desired side-effects include operations which
>>> are not simple to script and ByteMan provides help in that area too.
>>> The extra features (beyond calls to Java operations or application
>>> APIs) that ByteMan provides out of the box are exposed via the Helper
>>> class. This class implements the default built-in methods available
>>> for use in scripts. These built-ins allow you to write simple, clear
>>> rules which do many of the things that are needed during testing.
>>>
>>> The default Helper provides 3 distinct sets of operations for:
>>> coordinating the timing of independent threads; creating and managing
>>> rule state from one rule triggering to the next; and generating
>>> output to trace progress of a test. I specifically implemented the
>>> first set to help enforce normal and abnormal timings during XTS
>>> crash recovery testing and they have been very useful when it comes
>>> to ensuring that tests run with both expected and unexpected
>>> interleavings. The second set allows scripts to succinctly express
>>> quite complex scenarios. The third set is just a basic way of dumping
>>> trace output to files.
>>>
>>> Now you _could_ implement the same functionality as a library to be
>>> called from AOP injected code. In fact its easy to do so because it's
>>> just the public API of a single class that I defined. But I don't
>>> think the resulting AOP-based code would be as quick to write, test
>>> and change, nor as clear and easy for others to read and follow. The
>>> rules I used in the TS tests are few in number, concise and express
>>> directly how they modify the behaviour of the application code.
>>> Anyone who understands the application can easily follow how these
>>> rules implement the desired test scenario.
>>>
>>> The same concern for clarity, simplicity and flexibility led me to
>>> provide support for redefinition of the helper class. I envisage that
>>> when testing a specific application there will be the need to perform
>>> common operations not contained in the set I provided. As with XTS
>>> these operations will be required in order to to set up, maintain and
>>> monitor test conditions across multiple triggerings and in different
>>> tests. By defining a helper class to encapsulate those operations you
>>> can still employ small, simple and clear rule sets to define the test
>>> scenarios.
>>>
>>> As regards performance, I don't yet know how well Byteman performs. I
>>> have not yet had a chance to test performance of either the trigger
>>> injection code or the rule type checker/compiler. The former is very
>>> efficient in that it avoids _any_ work if a loaded class does not
>>> match a rule in the current rule set i.e. the target class and target
>>> method do not hash to values mentioned in the rule base or. If they
>>> do match, then a very simple bytecode scan filters out methods which
>>> do not contain a location matching the rule specification (e.g. there
>>> is no read of a field call name).
>>>
>>> If a method does match a rule's class, method and lcocation then the
>>> transformer code still only performs a relatively simple modification
>>> of the bytecode. It injects a single call to the rule engine at each
>>> trigger location and provides a catch block for the potential
>>> exceptions thrown by that call. This involves a single walk through
>>> the bytecode for each matched rule. It's not quite so simple as just
>>> throwing in a few LOADS and an INVOKE_STATIC call since doing the
>>> exception handling correctly requires identifying enough of the
>>> control flow to ensure that synchronized blocks are exited cleanly.
>>> But I still expect this transformation to be very fast (if it is not
>>> then of course we could probably switch to using AOP to do the job,
>>> but I don't suppose that is likely to do a lot better ;-)
>>>
>>> The type checker is pretty simple also, especially if the rules are
>>> kept compact. The overhead of type checking (and compilation to
>>> bytecode) are determined by the complexity of the rule body since
>>> both involve little beyond a simple walk of the rule parse tree
>>> (another reason to define custom helpers for test-specific
>>> operations). Once again I expect them to be very fast. Type checking
>>> is done at first execute so any cost is not incurred unless and until
>>> a rule is triggered. By default rules are run interpreted. I have
>>> found with my tests that rules are triggered only once or twice and I
>>> envisage that this will be common since setting up and tarcing test
>>> scenarios usually requires a small number of tweaks at very specific
>>> points in the code. However, rule compilation i.e. translation of the
>>> rule body to invokable bytecode has now been implemented so it should
>>> help in cases where rules are triggered frequuemtly. The initial crop
>>> of obvious bugs have been fixed and I'll be happy to get my teeth
>>> into the harder ones as they turn up (so please break it :-).
>>>
>>> regards,
>>>
>>>
>>> Andrew Dinn
>>> -----------
>>> _______________________________________________
>>> jboss-development mailing list
>>> jboss-development at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>
>

-- 
JBoss, a Division of Red Hat
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire,
SI4 1TE, United Kingdom.
Registered in UK and Wales under Company Registration No. 3798903
Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons
(USA)  and Brendan Lane (Ireland)

-- 
JBoss, a Division of Red Hat
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod 
Street, Windsor, Berkshire,
SI4 1TE, United Kingdom.
Registered in UK and Wales under Company Registration No. 3798903
Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons
(USA)  and Brendan Lane (Ireland)