Author Topic: Running bash scripts as transaction behaviour  (Read 26032 times)

TheKahn

  • Newbie
  • *
  • Posts: 15
  • Karma: +0/-1
Running bash scripts as transaction behaviour
« on: October 27, 2015, 09:28:03 PM »
Hello,

my name is Kamil Filar and I am currently working on my master thesis in Computer Science with the topic "Energy efficiency metrics for virtualized network functions". at the University of Würzburg (Germany). And I am using the Chauffeur WDK for the energy measurement, as you might have guessed.

The problem with my topic is, that my workloads are not generated on the SUT's processor but rather the network card.  I use Ostinato in order to generate custom traffic, which is send to the SUT's network card. I know that Chauffeur was designed to facilitate energy measurements for processor workloads but I need to ask you if the following transaction behaviour would be possible in Chauffeurs current implementation (1.1.0).

I plan to build a transaction that acts as follows.

  • On the host computer (in my case a Linux environment) a simple command is being executed . The transaction will then actively wait for the ending of the command.
  • After the transaction is finished, the listener will gather the screen output in order to compute the performance metrics.

I am using the following commands to limit the spawning of multiple transactions

Code: [Select]
<num-transaction-threads>1</num-transaction-threads>
<max-per-client-users>1</max-per-client-users>


My questions are now the following ones:

  • How can I reduce the spawning of transactions in Chauffeur to exact one transaction?
  • How can I tell the host to run a bash command and print out everything on screen? I orientated myself on the List<String> getLscpuEntries() method but somehow the transaction is spawned multiple times before it can even finish one complete run and there is no response from the comand prompt on the host's screen.


Please tell me if you need more information.

Thank you very much in advance.

Yours Sincerely

Kamil


JeremyArnold

  • Moderator
  • Newbie
  • *****
  • Posts: 15
  • Karma: +1/-0
Re: Running bash scripts as transaction behaviour
« Reply #1 on: November 08, 2015, 10:29:47 PM »
Hi,
The type of transaction you describe should run just fine in Chauffeur.  As you say, your transaction code will need to launch the command, wait for it to return, and then collect the output.

In addition to setting <num-transaction-threads> and <max-per-client-users> in config.xml, you'll probably want to set the client count to 1 (in <client-configuration>).  If you have done those three things, and your Transaction code properly blocks until the command completes, there should only be one copy of your transaction code running at a time.  If you are seeing the transaction return immediately without waiting for the command to complete, then there is an issue in your Transaction code, or the script you are executing is returning without waiting for the workload to complete.  The getLscpuEntries() code should be a reasonable example.  If you're having trouble with it, feel free to post your code and I'll see if I can help.

It sounds like you also want to only run one transaction total.  To do this, you'll want to use a FixedIterationsDirectorSequence.  Instead of <sequence>, use:
   <sequence className="org.spec.chauffeur.director.FixedIterationsDirectorSequence">
      <interval-iterations>1</interval-iterations>
      ...
   </sequence>

Another alternative is the MinIterationsDirectorSequence -- this is useful when there are multiple threads and/or clients, because it will keep running transactions in all clients until the last one has completed the minimum number you specify.  That way you can ensure that the system continues running at a steady load while collecting power data.

The drawback of either of these approaches is that they can't generate graduated loads like the default behavior can.  For example, you won't be able to generate a 25% or 50% load this way.

You may also be interested in the ScoreCalculator interface, which would allow you to base the worklet's score on the output returned by your command, instead of the default throughput-based score.  You'll need to implement the org.spec.chauffeur.ScoreCalculator interface.  There are two implementations in Chauffeur that you can look at for examples:  the ThroughputCalculator (the default) and TransactionResultsScoreCalculator.  It may even be possible to use the TransactionResultsScoreCalculator directly: just define your transaction to return a numeric value, and the TransactionResultsScoreCalculator will use that value as the worklet score.  Whether you use this implementation or your own custom implementation, you'll need to define it in your worklet xml file:
    <score-calculator-factory implClass="org.spec.chauffeur.TransactionResultsScoreCalculator"/>

I hope that helps.  If you have any further questions, please respond and I'll try to reply more quickly.

TheKahn

  • Newbie
  • *
  • Posts: 15
  • Karma: +0/-1
Re: Running bash scripts as transaction behaviour
« Reply #2 on: November 14, 2015, 09:58:57 AM »
Hello and thank you for your input.

After I changed the sequence the transaction has been executed only once. However, somehow it looks that my transaction does not work. I tried even a very simple transaction consisting of a simple printline command. Nevertheless, neither on the director nor on the host console the printline command worked. I tried to orientate myself on the available tutorial. I will post my configuration files and my code snippets and try to explain what I tried to achieve with them.


My configuration:

Code: [Select]
<?xml version="1.0" encoding="UTF-8"?>
<chauffeur xmlns="http://spec.org/power_chauffeur"
   xmlns:xi="http://www.w3.org/2001/XInclude">
<xi:include href="test-environment.xml"/>


<suite>
<client-configuration>
<clients key="Test">
<count>1</count>
<option-set/>
</clients>
</client-configuration>

<description className="org.spec.chauffeur.test.ChauffeurTest"/>
classpath="lib/chauffeurTest.jar"/>


<xi:include href="listeners.xml"/>

<workload enabled="true">
<name>Energy Efficiency Metrics Test</name>
<worklet enabled="true">

<launch-definition id="launchDef">
<configuration-key>Test</configuration-key>
</launch-definition>

<workletDefinition>
<location>org/spec/chauffeur/energyEfficiencyMetrics/testWorklet.xml</location>
<classpath>
<entry>lib/energy.jar</entry>
</classpath>
<parameters>
<parameter name="minimum-sleep-time">500ms</parameter>
<parameter name="maximum-sleep-time">5000ms</parameter>
</parameters>
</workletDefinition>

<warmup-phase>
<sequence className="org.spec.chauffeur.director.FixedIterationsDirectorSequence">
<interval-series className="NoDelaySeries">
<scenario-mix-factory>energyEfficiencyScenarioMix</scenario-mix-factory>
</interval-series>
<interval-iterations>1</interval-iterations>
</sequence>
</warmup-phase>

<calibration-phase>
<sequence className="org.spec.chauffeur.director.FixedIterationsDirectorSequence">
<interval-series className="NoDelaySeries">
<scenario-mix-factory>energyEfficiencyScenarioMix</scenario-mix-factory>
</interval-series>
<interval-iterations>1</interval-iterations>
</sequence>
<calibrator className="AverageThroughputCalibrator">
<average-intervals>2</average-intervals>
</calibrator>
</calibration-phase>

<measurement-phase>
<sequence className="org.spec.chauffeur.director.FixedIterationsDirectorSequence">
<interval-series className="GraduatedMeasurementSeries">
<scenario-mix-factory>energyEfficiencyScenarioMix</scenario-mix-factory>
</interval-series>
<interval-iterations>1</interval-iterations>
</sequence>
</measurement-phase>

<num-transaction-threads>1</num-transaction-threads>
<max-per-client-users>1</max-per-client-users>

</worklet>
</workload>
</suite>
</chauffeur>





My worklet definition:

Code: [Select]
<?xml version="1.0" encoding="UTF-8"?>
<workletDefinition xmlns="http://spec.org/power_chauffeur">
<name>Energy Efficiency Test Worklet</name>
<user-factory className="org.spec.chauffeur.energyEfficiencyMetrics.EnergyEfficiencyUserFactory"/>
<launch-customizer className="CpuLaunchCustomizer"/>

<default-scenario-mix-factory>energyEfficiencyScenarioMix</default-scenario-mix-factory>
<scenario-mix-factories>
<scenario-mix-factory name="energyEfficiencyScenarioMix">
<scenarios>
<weighted-scenario>
<weight>1</weight>
<scenario-factory implClass="org.spec.chauffeur.Scenario">
<batch-size>1</batch-size>
<macro-transaction-size>1</macro-transaction-size>
<transaction-mix-factory>
<weighted-transaction>
<transaction-factory implClass="org.spec.chauffeur.energyEfficiencyMetrics.EnergyEfficiencyMetricsTransaction"/>
<weight>1</weight>
</weighted-transaction>
</transaction-mix-factory>
</scenario-factory>
</weighted-scenario>
</scenarios>
</scenario-mix-factory>
</scenario-mix-factories>
</workletDefinition>


My UserFactory (As the user does not play a role in my test scenario because I generate my network traffic with a differnt application, the factory does nothing):


Code: [Select]
public class EnergyEfficiencyUserFactory extends
AbstractUserFactory<EnergyEfficiencyUser> {

public EnergyEfficiencyUserFactory() throws IOException {
}

@Override
public synchronized EnergyEfficiencyUser createUser(
WorkletContext<EnergyEfficiencyUser> workletContext, int userId)
throws InvalidConfigurationException, FatalWorkletException {
return new EnergyEfficiencyUser(workletContext.getWorklet(), userId);
}
}


My user (As said before, users are not important in my setup):


Code: [Select]
public class EnergyEfficiencyUser extends AbstractUser {
public EnergyEfficiencyUser(Worklet<EnergyEfficiencyUser> worklet, int userId) throws InvalidConfigurationException {
super(worklet, userId);
}
}


And my reduced test transaction (All will play here. As I said before, I plan to start bash commands here, wait for the result and then collect the results. This reduced transaction consists only of one print command as I want simply see that the transaction works and displays the string on the host (and director) console.  Also the result verification is not implemented yet. Also I plan to parameterize the static class variables in the future).


Code: [Select]
public class EnergyEfficiencyMetricsTransaction extends
Transaction<EnergyEfficiencyUser, String, Boolean> {

private static final String command = "echo 'password' | sudo -S python";
private static final String path = " /usr/local/lib/python2.7/dist-packages/ostinato/";

@Override
public String generateInput(EnergyEfficiencyUser user)
throws TransactionFailedException, FatalWorkletException {

return "Nothing";
}

@Override
public Boolean process(EnergyEfficiencyUser user, String word)
throws TransactionFailedException, FatalWorkletException {

String finalCommand = command + path + "firewallTest0" + ".py";

System.out.println("It's working!");

return true;
}

@Override
public boolean verifyResults(EnergyEfficiencyUser user, String input,
Boolean results) {
return true;
}

@Override
public String getTransactionName() {
return "Firewall";
}
}


I personally do not know where my error lies. According to the tutorial, the transaction should work. But it has no effect on the console.

Have I made some mistakes in the configuration or does simple print commands not work. However, by looking through the other code, there are plenty of other print commands, which clearly works.

Thank you very much in advance.
« Last Edit: November 15, 2015, 05:55:25 AM by TheKahn »

JeremyArnold

  • Moderator
  • Newbie
  • *****
  • Posts: 15
  • Karma: +1/-0
Re: Running bash scripts as transaction behaviour
« Reply #3 on: November 18, 2015, 11:20:21 AM »
The transaction will run in the Chauffeur Client JVM, so your println output won't appear in the Director or Host console.  It should go to the client.0.out file.

At a glance, your code looks like it should be okay.  I can take a closer look if you're not seeing the output in client.0.out

TheKahn

  • Newbie
  • *
  • Posts: 15
  • Karma: +0/-1
Re: Running bash scripts as transaction behaviour
« Reply #4 on: November 18, 2015, 05:37:39 PM »
Hi,

I looked at my client.0.out but the no entry in the log.

Here is the log by the way, as my host runs on a Ubuntu Server 14.04.2  the lspu command does not work, the numactl alternative works however.


Code: [Select]
Connecting to Host at localhost:58792
Nov 14, 2015 1:41:50 PM org.spec.chauffeur.client.ClientJvm main
INFORMATION: Connection established to Host at localhost:58792
Nov 14, 2015 1:41:51 PM org.spec.chauffeur.env.LinuxEnvironment getNodeList
WARNUNG: Exception occurred while discovering CPU topology via lscpu.  Attempting to use numactl / cpuinfo.
java.io.IOException: Output on stderr while running 'lscpu -a -p=CPU,CORE,SOCKET,NODE,CACHE,ONLINE': lscpu: $
        at org.spec.chauffeur.env.LinuxEnvironment.getLscpuEntries(LinuxEnvironment.java:347)
        at org.spec.chauffeur.env.LinuxEnvironment.initNodeListViaLscpu(LinuxEnvironment.java:196)
        at org.spec.chauffeur.env.LinuxEnvironment.getNodeList(LinuxEnvironment.java:184)
        at org.spec.chauffeur.env.LinuxEnvironment.getNumaNodeCount(LinuxEnvironment.java:178)
        at org.spec.chauffeur.env.AbstractEnvironment.toString(AbstractEnvironment.java:661)
        at java.lang.String.valueOf(String.java:2994)
        at java.lang.StringBuilder.append(StringBuilder.java:131)
        at org.spec.chauffeur.client.ClientJvm.main(ClientJvm.java:145)

Nov 14, 2015 1:41:51 PM org.spec.chauffeur.common.Communicator sendRequest
INFORMATION: Sending request 'OutputMessage: [Chauffeur, 4, org.spec.chauffeur.host.ClientInfo@ca001df6]' to Host 'send$
Nov 14, 2015 1:41:51 PM org.spec.chauffeur.AbstractSuite checkClasspathSignatures
WARNUNG: Signature verification failed because signature information not available
Nov 14, 2015 1:41:51 PM org.spec.chauffeur.AbstractSuite verifySignatures
WARNUNG: Signature verification failed because signature information not available
Nov 14, 2015 1:41:51 PM org.spec.chauffeur.common.Communicator sendRequest
INFORMATION: Sending request 'OutputMessage: [0]' to Host 'sender'
Running suite ChauffeurTest with Chauffeur 1.1.0 (20150505)
Nov 14, 2015 1:41:51 PM org.spec.chauffeur.common.Communicator sendRequest
INFORMATION: Sending request 'OutputMessage: [0]' to Host 'sender'
Running workload Energy Efficiency Metrics Test
ClientWorklet.maxUsers: 1
Nov 14, 2015 1:41:51 PM org.spec.chauffeur.common.Communicator sendRequest
INFORMATION: Sending request 'OutputMessage: [0]' to Host 'sender'
Running worklet Energy Efficiency Test Worklet
Forcing GC before worklet
Nov 14, 2015 1:41:51 PM org.spec.chauffeur.AbstractSuite verifySignatures
WARNUNG: Signature verification failed because signature information not available
Nov 14, 2015 1:41:51 PM org.spec.chauffeur.common.Communicator sendRequest
INFORMATION: Sending request 'OutputMessage: [0]' to Host 'sender'
Started ClientPhase[warmup]
Nov 14, 2015 1:41:51 PM org.spec.chauffeur.common.Communicator sendRequest
INFORMATION: Sending request 'OutputMessage: [0]' to Host 'sender'
Started sequence ClientSequence[sequence]
Nov 14, 2015 1:41:51 PM org.spec.chauffeur.common.Communicator sendRequest
INFORMATION: Sending request 'OutputMessage: [0, org.spec.chauffeur.metrics.Metrics@1c53fd30]' to Host 'sender'
Completed sequence ClientSequence[sequence]
Nov 14, 2015 1:41:51 PM org.spec.chauffeur.common.Communicator sendRequest
INFORMATION: Sending request 'OutputMessage: [0, org.spec.chauffeur.metrics.Metrics@282ba1e]' to Host 'sender'
Completed ClientPhase[warmup]
Nov 14, 2015 1:41:52 PM org.spec.chauffeur.common.Communicator sendRequest
INFORMATION: Sending request 'OutputMessage: [0]' to Host 'sender'
Started ClientPhase[calibration]
Nov 14, 2015 1:41:52 PM org.spec.chauffeur.common.Communicator sendRequest
INFORMATION: Sending request 'OutputMessage: [0]' to Host 'sender'
Started sequence ClientSequence[sequence]
Nov 14, 2015 1:41:52 PM org.spec.chauffeur.common.Communicator sendRequest
INFORMATION: Sending request 'OutputMessage: [0, org.spec.chauffeur.metrics.Metrics@13b6d03]' to Host 'sender'
Completed sequence ClientSequence[sequence]
Nov 14, 2015 1:41:52 PM org.spec.chauffeur.common.Communicator sendRequest
INFORMATION: Sending request 'OutputMessage: [0, org.spec.chauffeur.metrics.Metrics@f5f2bb7]' to Host 'sender'
Completed ClientPhase[calibration]
Nov 14, 2015 1:41:52 PM org.spec.chauffeur.common.Communicator sendRequest
INFORMATION: Sending request 'OutputMessage: [0, org.spec.chauffeur.metrics.Metrics@73035e27]' to Host 'sender'
Worklet Energy Efficiency Test Worklet completed
Nov 14, 2015 1:41:52 PM org.spec.chauffeur.common.Communicator sendRequest
INFORMATION: Sending request 'OutputMessage: [0, org.spec.chauffeur.metrics.Metrics@64c64813]' to Host 'sender'
Workload Energy Efficiency Metrics Test completed
Nov 14, 2015 1:41:52 PM org.spec.chauffeur.common.Communicator sendRequest
INFORMATION: Sending request 'OutputMessage: [0, org.spec.chauffeur.metrics.Metrics@3ecf72fd]' to Host 'sender'
Suite ChauffeurTest completed
Nov 14, 2015 1:41:52 PM org.spec.chauffeur.AbstractSuite verifySignatures
WARNUNG: Signature verification failed because signature information not available

Thank you very much in advance.

TheKahn

  • Newbie
  • *
  • Posts: 15
  • Karma: +0/-1
Re: Running bash scripts as transaction behaviour
« Reply #5 on: December 13, 2015, 10:41:36 AM »
Hi, after some experimentation I progressed a litte bit further.

I found out that I need to add this line "<interval-count>[ANY POSITIVE INT]</interval-count>" in the <interval-series> configuration to be able to run the transaction.

Also I found out that in my worklet definition I had to chose a different implementation for a scenario factory. I chose the RandomBatchScenario scenario-factory.

Unfortunatley I enouctered another error. I made sure that are created by the userFactory. Unfortunately, the generation of Input and Transaction does not start.

This is the error I encountered:


Code: [Select]
Exception during execution
org.spec.chauffeur.common.ProtocolException: Expected command 'startPremeasurement','runPremeasurement', 'startRecording','runMeasurement', 'endRecording','measurementComplete', 'endInterval', 'initializationComplete', 'premeasurementComplete', 'runPostmeasurement', 'postmeasurementComplete', or 'intervalResults' but got 'endSequence'
        at org.spec.chauffeur.host.HostInterval.processCommands(HostInterval.java:304)
        at org.spec.chauffeur.host.HostInterval.runInterval(HostInterval.java:355)
        at org.spec.chauffeur.host.HostSequence.processCommands(HostSequence.java:134)
        at org.spec.chauffeur.host.HostSequence.runSequence(HostSequence.java:195)
        at org.spec.chauffeur.host.HostPhase.processPhaseCommands(HostPhase.java:151)
        at org.spec.chauffeur.host.HostPhase.runPhase(HostPhase.java:245)
        at org.spec.chauffeur.host.HostWorklet.processCommands(HostWorklet.java:140)
        at org.spec.chauffeur.host.HostWorklet.runWorklet(HostWorklet.java:204)
        at org.spec.chauffeur.host.HostWorkload.runWorklet(HostWorkload.java:189)
        at org.spec.chauffeur.host.HostWorkload.processCommands(HostWorkload.java:120)
        at org.spec.chauffeur.host.HostWorkload.runWorkload(HostWorkload.java:173)
        at org.spec.chauffeur.host.HostSuite.runWorkload(HostSuite.java:187)
        at org.spec.chauffeur.host.HostSuite.processCommands(HostSuite.java:115)
        at org.spec.chauffeur.host.HostSuite.runSuite(HostSuite.java:171)
        at org.spec.chauffeur.host.Host.main(Host.java:162)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:497)
        at org.spec.chauffeur.Launcher.main(Launcher.java:68)

Here are my questions:

1. Am I missing some configuration lines for the  FixedIterationsDirectorSequence, if yes which lines are missing?
2. I noticed that neither the transaction in the tutorial or the the transaction in the ChauffeurTest Suite directly call the process method. Am I required to explicitly call the prcoess method in order to get the transaction to run in the FixedIterationsDirectorSequence or not?
3. Am I missing something else I am not aware of?

I have attached my logs and configuration files.

Thank you very much in advance.

Cheers
« Last Edit: December 13, 2015, 10:44:57 AM by TheKahn »

JeremyArnold

  • Moderator
  • Newbie
  • *****
  • Posts: 15
  • Karma: +1/-0
Re: Running bash scripts as transaction behaviour
« Reply #6 on: December 16, 2015, 11:18:37 AM »
Glad to see you are making progress.

I believe you've hit a bug in the WDK with the FixedIterationsDirectorSequence.  The simplest workaround may be to switch to the MinIterationsDirectorSequence.  I believe that for what you are running, it will behave the same way as the FixedIterationsDirectorSequence (except that it should work).

The actual fix (not yet tested) would be to edit org/spec/chauffeur/director/FixedIterationsDirectorInterval.  In the runInterval method, find the line:
    Map<String, IntervalResults> results = hosts.readIntervalResults(responses);
Just before that line, add:
    responses = hosts.sendCommand(loader, "intervalResults");

We'll make sure that this fix is included in the next release of the WDK.


You should not need to call the process method explicitly -- Chauffeur will call it for you.

TheKahn

  • Newbie
  • *
  • Posts: 15
  • Karma: +0/-1
Re: Running bash scripts as transaction behaviour
« Reply #7 on: December 17, 2015, 06:19:52 AM »
Hi,

your fix worked. I have found another error but this is a configuration error. At least I persume so.

The FixedIterationDirectorInterval has three variables:

  • premeasurementIterations
  • measurementIterations
  • postmeasurementIterations


However these are not assigned. I have tried the following configurations but none of them worked and some of them throw build errors:

This one could not be parsed!

Code: [Select]
<interval-iterations>
   <premeasurementIterations>1</premeasurementIterations>
   <measurementIterations>1</measurementIterations>
   <postmeasurementIterations>1</postmeasurementIterations>
</interval-iterations>

This configuration could be parsed but the variables were still 0

Code: [Select]
<interval-iterations premeasurementIterations="1" measurementIterations="1" postmeasurementIterations="1">3</interval-iterations>
Same with this one.


Code: [Select]
<interval-iterations pre="1" measurement="1" post="1">3</interval-iterations>      


What should the correct configuration be?


Thank you very much in advance.

Cheers   

TheKahn

  • Newbie
  • *
  • Posts: 15
  • Karma: +0/-1
Re: Running bash scripts as transaction behaviour
« Reply #8 on: December 19, 2015, 11:40:44 AM »
Hi there,

it works now after  I used the following configuration:

Code: [Select]
<interval-iterations>
        <premeasurement>1</premeasurement>
        <measurement>1</measurement>
        <postmeasurement>1</postmeasurement>
</interval-iterations>

I orientated myself first on the variable names of the IntervallIterations class but this did not work (could it be another bug?).

Interssting thing: You do not have to use different names for the configuration of the IntervallLength class.

Cheers :)

TheKahn

  • Newbie
  • *
  • Posts: 15
  • Karma: +0/-1
Re: Running bash scripts as transaction behaviour
« Reply #9 on: December 27, 2015, 04:59:10 PM »
Hi there,

a late Merry Christmas at first :)

After experimenting a little bit I came into the need of a graduate measurement. As stated it is not possible with the fixedIterationsSequence but is there a suite that could run a SERIES of fixedIterationsSequences?

1. If there is one could you please tell me which one?
2. If there is no one could you please tell me which class is close to the described behaviour (below)?


Behaviour:

1. Running one fixedIterationsSequence completely
2. After finishing the running of the sequence in one, a different sequence will be started and processed.
3. Repeat step 1-2 until every defined sequence in the configuration file has been processed.


Thank you very much in advance

Cheers

TheKahn

  • Newbie
  • *
  • Posts: 15
  • Karma: +0/-1
Re: Running bash scripts as transaction behaviour
« Reply #10 on: January 02, 2016, 02:31:33 PM »
The ThrougputPercentageSeries did the trick for me... :)

Now I need to focus myself on the listener, as unfortunately the transaction cannot access the current percentage level .... :(

Just a question: Why the desgin decision, that the transaction may not have access to the current name of the interval (often the percentage?) or did I miss something and there is actually an option to get this variable in the scope of the transaction?

Happy new year :)

Cheers

JeremyArnold

  • Moderator
  • Newbie
  • *****
  • Posts: 15
  • Karma: +1/-0
Re: Running bash scripts as transaction behaviour
« Reply #11 on: January 05, 2016, 11:08:52 AM »
I'm glad to see you are continuing to make progress -- I apologize for the delay while I was on vacation.

Depending on your requirements, you might find the ModifyParametersSeries to be more appropriate than the ThroughputPercentageSeries.  With the ModifyParametersSeries, you can create your own list of intervals, and set what parameters you'd like for each interval.  Here's an example from SERT:
Code: [Select]
<interval-series className="ModifyParametersSeries">
<launchDefinition ref="memoryLaunchDef"/>

<intervals>   
<interval>
<name>Flood_Full</name>
<transaction-parameters>
<transaction>
<name>TxFlood</name>
<parameter name="load-level">1.0</parameter>
</transaction>
</transaction-parameters>
</interval>

<interval>
<name>Flood_Half</name>
<transaction-parameters>
<transaction>
<name>TxFlood</name>
<parameter name="load-level">0.5</parameter>
</transaction>
</transaction-parameters>
</interval>
</intervals>
</interval-series>

For the listeners, the intervalEnding (and similar) event gets an IntervalEvent.  event.getContext() will return an IntervalContext.  context.getInterval() will return an Interval, and interval.getName() will return the name.  So I think you should be able to get to it.  I normally try to avoid using the name for anything since there isn't a guarantee of a particular format.  But for your purposes it will probably work fine.  If you have suggestions about additional information that should be available to listeners, let me know and we can consider changes for a future release.

TheKahn

  • Newbie
  • *
  • Posts: 15
  • Karma: +0/-1
Re: Running bash scripts as transaction behaviour
« Reply #12 on: January 07, 2016, 06:31:05 PM »
Hi there, good that you are back.

OK I managed to implement myListener but unfortunately the communication works only in one way. I can listen and get and manipulate the workletContext but unfortunately I cannot pass it back.

By the way the passingParametersSeries does not substitute the parameters for some reason. So I figured a way to write my own passing. For this I need the UserFactory in which I need to access my Listener and get the list of substituted ConfigObjects (the Listener is able to read them in the init phase without any problems [well I cheated and had to change the visibility of the getIntervalDef in the AbstractInterval Class, sorry for that).

 Then I can substitute the parameteres in the worklet context before creating a user. 

However, there is no method to access an Listener, I wrote for test reasons a simple method in the Suite Context:

Code: [Select]
//YOU NEED THIS METHOD SERIOUSLY!!! - Kamil Filar
public synchronized RunListener getListener(RunListener listener) {
    RunListener returnListener = null;
    for (RunListener runListener : getListeners()) {
    if(runListener.getClass().equals(listener.getClass())){
returnListener = listener;
break;
    }
}
   
    if(returnListener == null){
logger.log(Level.SEVERE, "The specifiedListener: " + listener.getClass() + " has not been assigend to the Suite Context!");
    }
   
    return returnListener;
}

it should get the attached listener. But somehow the Listener is not persistent and I don't know how to pass variables from the listener to other classes.

Moreover, a different question: How can I disable the RunWriterListener, which is started as default in the ClientJVM and HOST as I wrote an own RunWriterListener to handle my own scores. I had to stop at some point as my final scores would be stored in an IntegerArray and not into a single numeric value and I know that it will lead to some null pointer errors if the standard implementation is still running (the deasginment from the listeners.xml did not work at all as this listener is started as default)


Sorry for bothering you.

Cheers

TheKahn

  • Newbie
  • *
  • Posts: 15
  • Karma: +0/-1
Re: Running bash scripts as transaction behaviour
« Reply #13 on: January 08, 2016, 01:09:25 PM »
OK I did it with a different approach.

I found that the Transaction class has an init function, which gives you the interval definition. I seriously did not saw this sweet little method earlier.

Nevertheless just out of curiosity: How would it be possible to access the listener from a different class OR how can the listener pass manipulated variables to other classes.


My most important question at the moment is: Can you and how can you deasign the standard RunWriterListener from the ClientJVM, as it is always assigned? I have my own version of this listener but this listener produces NullPointerExceptions when I pass not numerical scores unfortunately :(


P.S. With my current approach I don't need the specific getListenerMethod anymore :)

However it is still imperative that the getIntervalDef Methods in the AbstractInterval classes need to be set to a public visibility as it is impossible to the the IntervalDefinition otherwise, so I have to keep this modification to the Chauffauer Source, Sorry.



Cheers

Kamil
« Last Edit: January 09, 2016, 11:06:12 AM by TheKahn »

JeremyArnold

  • Moderator
  • Newbie
  • *****
  • Posts: 15
  • Karma: +1/-0
Re: Running bash scripts as transaction behaviour
« Reply #14 on: January 12, 2016, 07:36:56 PM »
I'm glad you found a solution.

Listeners are intentionally designed to be passive, and not be able to influence the behavior of the worklets.  I'm not inclined to change that behavior.  I'd prefer to use more explicit control mechanisms for cases like this. 

For the default listeners -- I was thinking you were referring to the RawFileWriter, but now I understand you meant the WriterRunListener, which writes run progress to System.out.  This is currently hard-coded (e.g. ClientJvm.main()).  That could be commented out, but perhaps the better solution would be to update the WriterRunListener implementation to avoid the exception.  Another option to consider would be to store your custom results in Metrics rather than returning it as the score, since Chauffeur pretty much assumes each interval has a single result for the interval.

For AbstractInterval, I would lean towards keeping getIntervalDef protected, but adding methods to the Interval interface to return information from the IntervalDef where appropriate (similar to the current getName() method).  But I could be convinced otherwise.  Can you remind me what information you are getting from the IntervalDef in your code?