-
1. Re: update sleep time failed
swimablefish Oct 26, 2011 1:48 AM (in response to swimablefish)maybe i should wait 300s, then run testcase2 ?
-
2. Re: update sleep time failed
adinn Oct 26, 2011 4:10 AM (in response to swimablefish)Hi swimable
swimablefish wrote:
In testcase1 when the thread call interface A's method B, i let it sleep 300s, then unload the script and submit new script to run testcase2 which let it sleep 20 s. But the result is that it still sleeps 300s. So i have to restart the process before run testcase2 and then submit new script. I wonder whether i operated incorrectly or it's a bug.
If you were to explain what you did i) to install the rule and ii) to redefine it we might be able to identify or rule out procedural errors. It would also be useful if you could give some indication of what the implementations of A.B() look like and where they are called from (in particular whether calls to AImpl.B() occur inside e.g. loop operations).
Specifically, in this case you need to be sure that there is no danger that your thread is already executing the rule at the point where you do the resubmit. If it is already insdie a call to sleep then redefining the rule will not wake it up. It should mean that the thread will only wait for 20 seconds at the next call though. One way to check this is to define our rule as follows:
RULE test
INTERFACE A
METHOD B
IF TRUE
DO debug("sleeping");
Thread.sleep(300 * 1000);
debug("wokeup")
ENDRULE
and then when you run your program add the command line argument
-Dorg.jboss.byteman.debug
Calls to builtin method debug(String) normally have no effect. However if system property org.jboss.byteman.debug is set then they print the string supplied as argument. If you runthis version of the rules then you will be able to see whether your thread is still inside a wait when you resubmit the rule.
As a general point, when you resubmit a rule that was previously injected Byteman ensures that the JVM retransforms the bytecode for the affected classes, removing the old injected code and inserting new injected code. By the time the resubmit operation has finished all of the affected methods' bytecode will definitely have been redefined. However, this does not mean that all threads which are currently running the affected methods will immediately switch to executing the new bytecode. In certain stuations, for example where a thread is directly executing the affected method or, possibly, where it is executing JITted native code which inlines the affected method, it is possible that there will be a small window following the update during which the thread continues to execute the old code. Although this is unlikely I canto ruule it out without further details.