I attempt with
val executors = Executors.newSingleThreadExecutor()
val scheduler = Schedulers.from(executors)
Observable.just[Int](1,2,3).subscribeOn(scheduler)
output a error
Error:(103, 43) type mismatch;
found : rx.Scheduler
required: rx.lang.scala.Scheduler
Observable.just[Int](1,2,3).subscribeOn(scheduler)
^
how to use custom Scheduler in RxScala?
The problem here is that you mix RxJava and RxScala code here. You see, RxScala is just a wrapper around the RxJava functionality; the former only forwards to the latter and does not have any 'real' implementations. This is useful as you only need to maintain 1 version rather than 2 or more.
The type of scheduler in your example is rx.Scheduler, so it is an RxJava Scheduler. However, subscribeOn requires you to provide an rx.lang.scala.Scheduler, which is an RxScala Scheduler. Hence you need to either convert the RxJava Scheduler to one from RxScala.
However, for your case there is a better way of doing things: wrap your Executors.newSingleThreadExecutor into a scala.concurrent.ExecutionContext using the fromExecutor factory method. Then wrap this into an rx.lang.scala.schedulers.ExecutionContextScheduler and you have the scheduler you can use in subscribeOn. Your code will look something like this (I included a print statement to see on which thread the stuff is running):
val e = ExecutionContext.fromExecutor(Executors.newSingleThreadExecutor)
val s = ExecutionContextScheduler(e)
Observable.just(1, 2, 3)
.subscribeOn(s)
.doOnNext(x => println(s"thread - ${Thread.currentThread().getName}, value - $x"))
.subscribe()
Related
So I am using a bean shell post processor and towards the end I am storing the result in a 2-D array. Result is stored this way.
testArray[0][0] = "1"
testArray[0][1] = "Test"
testArray[1][0] = "2"
testArray[1][1] = "STG"
My requirement is that I need to pass this 2-D array to the next thread. How am I supposed to proceed ?
First of all since JMeter 3.1 you're supposed to be using JSR223 Test Elements and Groovy language for scripting so consider migrating to Groovy.
Coming back to your question just use props shorthand like:
In first thread:
props.put("testArray", testArray);
in the other thread:
testArray = props.get("testArray");
you might also want to add the current thread number as the prefix/postfix so different threads could have different arrays with separate values like:
props.put("testArray_" + ctx.getThreadNum(), testArray);
where ctx stand for JMeterContext class instance
More information on these ctx, props and other JMeter API shortcuts available for JSR223 Test elements: Top 8 JMeter Java Classes You Should Be Using with Groovy
I have a JMeter 5.2.1 project where in the SetUp thread I generate properties with names like ThreadGroupName1-NumberOfThreads, ThreadGroupName2-NumberOfThreads, etc. with values representing integers.
Now, I wish to access these properties in thread groups named ThreadGroupName1, ThreadGroupName2, etc. to parametrize the number of threads. I tried something like ${__jexl3(props.get(threadName + "-NumberOfThreads"))} but it fails as threadName evaluates to standardjmeterengine.
Also, I tried to use ctx but ctx.getThread() and ctx.getThreadGroup() but they evaluate to null.
So far what 'works' for me is ${__jexl3(props.get("ThreadGroupName1-NumberOfThreads"))} but I want it be parametrized by the name of the thread group.
Is it possible to do this?
Is this threadName returning standardjmeterengine a bug?
Update: In fact, the easiest 'solution' that provides the parametrized number of threads there is ${__P(ThreadGroupName1-NumberOfThreads)} and what I want is to generate this key ThreadGroupName1-NumberOfThreads to be something like ${MyCurrentGroupName}-NumberOfThreads, effectively providing a way to have an abstract method like
int GetNumberOfThreads(string threadGroupName)
{
return properties.get(threadGroupName + "-NumberOfThreads";
}
Similarly, I wish to use this patter in Constant Throughput Timer as well with another prefix like -Rpm.
I don't think you can use any JMeter Function in the "Number of Threads" field of the Thread Group so this is not something you can do via UI. If you believe this is something everyone needs you can consider raising an enhancement request
As a workaround you can
Set the number of threads to 1
Add If Controller to the Thread Group and use the following __groovy() function as the condition:
${__groovy(ctx.getThreadNum() == 0 && vars.getIteration() == 1,)}
Add JSR223 Sampler as a child of the If Controller and put the following code into "Script" area:
SampleResult.setIgnore()
2.upto(props.get(ctx.getThreadGroup().getName() + '-NumberOfThreads') as int, { ctx.getThreadGroup().addNewThread(0, ctx.getEngine()) })
This way each thread Group will normally start with 1 thread, however this thread will read the property you defined earlier and add as many threads as needed.
You can use JMeterContext's getThreadNum to get thread number (increment, because it starts with 0)
${__jexl3(props.get("ThreadGroupName"))}${__jexl3((ctx.getThreadNum()+1) + "-NumberOfThreads" )}
I am using pyfmi to do simulations with EnergyPlus. I recognized that initializing the individual EnergyPlus models takes quite some time. Therefore, I hope to find a way to initialize the models in parallel. I tried the python library multiprocessing with no success. If it matters, I am on Ubuntu 16.10 and use Python 3.6.
Here is what I want to get done in serial:
fmus = {}
for id in id_list:
chdir(fmu_path+str(id))
fmus[id] = load_fmu('f_' + str(id)+'.fmu',fmu_path+str(id))
fmus[id].initialize(start_time,final_time)
The result is a dictionary with ids as key and the models as value: {id1:FMUModelCS1,id2:FMUModelCS1}
The purpose is to call later the models by their key and do simulations.
Here is my attempt with multiprocessing:
def ep_intialization(id,start_time,final_time):
chdir(fmu_path+str(id))
model = load_fmu('f_' + str(id)+'.fmu',fmu_path+str(id))
model.initialize(start_time,final_time)
return {id:model}
data = ((id,start_time,final_time) for id in id_list)
if __name__ == '__main__':
pool = Pool(processes=cpus)
pool.starmap(ep_intialization, data)
pool.close()
pool.join()
I can see the processes of the models in my system monitor but then the script raise an error because the models are not pickable:
MaybeEncodingError: Error sending result: '[{id2: <pyfmi.fmi.FMUModelCS1 object at 0x561eaf851188>}]'. Reason: 'TypeError('self._fmu,self.callBackFunctions,self.callbacks,self.context,self.variable_list cannot be converted to a Python object for pickling',)'
But I cannot imagine that there is no way to initialize the models in parallel. Other frameworks/libraries than threading/multiprocessing are also welcome.
I saw this answer but it seems that it focuses on the simulations after initialization.
The answer below the one you refer to seems to explain what the problem with multiprocessing and FMU instantiation is.
I tried with pathos suggested in this answer, but run into the same problem:
from pyfmi import load_fmu
from multiprocessing import Pool
from os import chdir
from pathos.multiprocessing import Pool
def ep_intialization(id):
chdir('folder' + str(id))
model = load_fmu('BouncingBall.fmu')
model.initialize(0,10)
return {id:model}
id_list = [1,2]
cpus = 2
data = ((id) for id in id_list)
pool = Pool(cpus)
out = pool.map(ep_intialization, data)
This gives:
MaybeEncodingError: Error sending result: '[{1: <pyfmi.fmi.FMUModelME2 object at 0x564e0c529290>}]'. Reason: 'TypeError('self._context,self._fmu,self.callBackFunctions,self.callbacks cannot be converted to a Python object for pickling',)'
Here is another idea:
I suppose the instantiation is slow because EnergyPlus links plenty of libraries into the FMU. If the components you are modelling all have the same interface (input, output, parameters), you can probably use a single FMU with an additional parameter that switches between the models.
This would be much more efficient: You would only have to instantiate a single FMU and could call it in parallel with different parameters and inputs.
Example:
I have never worked with EnergyPlus, but maybe the following example will illustrate the approach:
You have three variants of a building and you are merely interested in the total heat flux over the entire surface area of buildings as a function of - "weather" (whatever that means - maybe a lot of variables).
Put all three buildings into a single EnergyPlus model and build an if or case clause around them (pseudo code):
if (id_building == 1) {
[model the building one]
elseif (if_building == 2) {
[model the building two]
[...]
Define the "weather" or whatever you need as an input variable for the FMU and define id_building also as a parameter. Define the overall heat flux as output variable.
This would allow you to choose the building before starting the simulation.
The two requirements are:
EnergyPlus Syntax allows if or case structures.
All your models work with the same interface (in our example we have weather as in and a flux as out variables)
There is a dirty workaround for the second requirement: Just define all the variables all your models need and only use what you need in the respective if block.
Coming from AngularJS I'm struggling trying to solve the next problem. I need a function that returns an object (lets call it A, but this object cannot be returned till all the requests that are contained in that function are resolved. The process should be like:
The object A is downloaded from a remote server
Using A, we do operations over another object (B)
B is downloaded from the server
B is patched using some attributes from A
Using A and the result of B we do operations over a third object, C
C is downloaded from the server
C is patched using some attributes from A and B
After B and C are processed, the function must return A
I'd like to understand how to do something like this using rxjs, but with Angular 6 most of the examples around the internet seem to be deprecated, and the tutorials out there are not really helping me. And I cannot modify the backend to make this a bit more elegant. Thanks a lot.
Consider the following Observables:
const sourceA = httpClient.get(/*...*/);
const sourceB = httpClient.get(/*...*/);
const sourceC = httpClient.get(/*...*/);
Where httpClient is Angular's HTTPClient.
The sequence of the operations you described may look as follows:
const A = sourceA.pipe(
switchMap(a => sourceB.pipe(
map(b => {
// do some operation using a and b.
// Return both a and b in an array, but you can
// also return them in an object if you wish.
return [a,b];
})
)),
switchMap(ab => sourceC.pipe(
map(c => {
// do some operations using a, b, and/or c.
return a;
})
))
);
Now you just need to subscribe to A:
A.subscribe(a => console.log(a));
You can read about RxJs operators here.
Well, first of all, it appears to me that this function-call, as described, would be somehow expected to block the calling process until all of the specified events have occurred – which of course is unreasonable in JavaScript.
Therefore, first of all, I believe that your function should require, as its perhaps-only parameter, a callback that will be invoked when everything has finally taken place.
Now – as to "how to handle steps 1, 2, and 3 elegantly" ... what immediately comes to mind is the notion of a finite-state machine (FSM) algorithm.
Let's say that your function-call causes a new "request" to be placed on some request-table queue, and, if necessary, a timer-request (set to go off in 1 millisecond) to service that queue. (This entry will contain, among other things, a reference to your callback.) Let's assume also that the request is given a random-string "nonce" that will serve to uniquely identify it: this will be passed to the various external requests and must be included in their corresponding replies.
The FSM idea is that the request will have a state, (attribute), such as: DOWNLOADING_FROM_B, B_DOWNLOADS_COMPLETE, DOWNLOADING_FROM_C, C_REQUESTS_COMPLETE, and so on. Such that each and every callback that will play a part in this fully-asynchronous process will (1) be able to locate a request-entry by its nonce, and then (2) unambiguously "know what to do next," and "what new-state (if any) to assign," based solely upon examination of the entry's state.
For instance, when the state reaches C_REQUESTS_COMPLETE, it would be time to invoke the callback that you originally provided, and to delete the request-table entry.
You can easily map-out all of the "state transitions" that might occur in an arbitrarily-complex scenario (what states can lead to what states, and what to do when they do), whether or not you actually create a data-structure to represent that so-called "state table," although sometimes it is even-more elegant(!) when you do. (Possibly-messy decision logic is simply pushed to a simple table-lookup.)
This is, of course, a classic algorithm that is applicable to – and, has been used in – "every programming language under the sun." (Lots of hardware devices use it, too.)
MongoIterable.forEach requires a Block which is very similar to Java 8 Consumer.
They are similar enough to cause problems, for example, the following doesn't compile:
MongoIterable<Document> result = collection.find(...);
result.forEach(System.out::println);
because the compiler can't decide between Iterable.forEach( Consumer ) and MongoIterable.forEach( Block ). Fixing this requires workarounds like explicitly typing the parameter:
Block<Document> printer = System.out::println;
result.forEach(printer);
or alternatively, treating MongoIterable as a plain Stream:
StreamSupport.stream(result.spliterator(), false).forEach(System.out::println);
Why is MongoIterable.forEach not defined using the Consumer interface, something like: MongoIterable.forEach(Consumer<? super TResult> consumer)? Even better - why have forEach in MongoIterable at all?
The Java driver still supports Java 6 as a target. So while the attempts were made to make the 3.0 driver Java 8 and lambda friendly, we couldn't use actual Java 8 interfaces.