I'm looking for an example of a unit test for a REDHAWK component. In particular, I'd like a test where I can provide packet(s) to an input port and verify the correct packet(s) are pushed from an output port. Is there a preferred way to do this with REDHAWK? I'm struggling to find documentation or examples.
Here is an example used by the HardLimit Component:
https://github.com/RedhawkSDR/HardLimit/blob/develop-1.0/tests/test_HardLimit.py
Basically, in the setUp method, a DataSource and DataSink from the REDHAWK Sandbox (sb) module are created, are started along with the Component, and then connected in the appropriate order.
Next, any method that starts with 'test' is run by the unit testing suite. Generally these methods will provide an array of data to the DataSource, which will format the data into BULKIO format and push to your Component. Assuming the Component is working correctly, it will push data to the DataSink, which can be checked periodically for new data. Once the data has been received, it can be validated as appropriate before the tearDown method is called.
Finally, the tearDown method stops and releases the Component and cleans up the source and sink.
This is the basic approach for testing a Component. There are more options available for sourcing and sinking data, which can be found by running the following in a python interpreter:
from ossie.utils import sb
help(sb)
This will also provide methods for plotting data and audio playback, among other miscellaneous utilities.
It is fairly easy with RedHawk to add a couple of new components: one to send packets to the component being tested and one to receive output packets. I make a sender or source packet using the serviceFunction() in sender.cpp which is called periodically if each call returns NORMAL, adding a usleep() if you want to control the rate. It should send a valid packet to its this->PortName->MethodName(). It can also randomly send bad packets too if you want to test how the component under test handles them. You can even add a component property to set the rate (using the value in the usleep).
The receiver or sink component can receive the packets in port_impl.cpp in MethodName() and do whatever test you want to test validity and either log the result of the test or use cout<
Related
I'm creating a system where users can chain together nodes, and data flows from one node to the other. At the end is a node which constantly pulls from the node before it, and does something with that data (e.g. for audio data, plays it). If you're familiar with FL Studio's Patcher, that's essentially what I'm trying to do:
The trivial implementation, which is to just have an interface like this:
interface Node {
byte[] getData();
}
where each node stores the one before it would work fine, except that I want to be able to have 2 nodes both requesting data from a single node, like this:
The issue here is that the source node is pulled twice every "step" (the intended behavior would be for the same value to be sent to both nodes). If you had for example an audio signal in the source node, the intended behavior would be for 2 different effects to be done to it, then the signals combined, while what would actually happen is that the signal is chopped up and each effect gets a different part of the signal depending on which happens to be called first.
What is a good way to solve this?
I have a SoapUI test which uses an input file to read lines as input of requests. So there is a loop which reads data and execute request and write output to file. Response times are too long, so processing of this file should be done asynchronously, but I am not sure, how SoapUI can handle this. There is file attachment in SOAP requests, which is not handled by current version of JMeter.
As per the SoapUI's documentation below, both test cases or test suites can be executed in Parallel mode.
In the case of TestSuites and TestCases these can be executed either in sequence or parallell, as configured with the corresponding toolbar buttons.
In the above image, first one in the marked image stands for sequential execution and the second one (with multiple parallel arrows) stands for Parallel execution mode.
User can select either of the one before executing the tests.
Hope this helps.
Note that SOAPUI does not allows test steps to be executed in parallel. If you need any custom execution i.e., same test case and steps to be executed in Parallel, here is sample project done for that. It can be used as reference and apply it to your case.
I understood this question as requiring the ability to call a service asynchronously due to the time it takes to process. So, by this, I mean SoapUI makes a request to a web service and instead of waiting for it, it carries on. At some point later, SoapUI receives the response.
SoapUI can handle this, I haven't tried it myself, but when reading some guides recently, I noticed it can be done.
See....
Blog Guide
SoapUI Forum
In short, it involves setting up a mock service to receive the response, which can then be validated.
I have a REST API, which returns me the latest sensor data when I make a GET request. New data is being added every second. I would like to make a GET request every second, so I can feed the latest sensor data to a line chart to keep the user updated and give it a real-time feeling.
Since Angular 4 is unable to create background threads, I'm unsure how I can do this task. I found some information regarding Web-Workers, however I was unable to find a proper example. I'm also unsure how I would use a Web-Worker to keep returning new data, as it usually only returns one value (when the function is finished executing).
Is this even possible using Angular 4?
I have a use case where I need a sequence to wait for a period of time before it continues. Basically it is a "Thread.Sleep(x)", but this would mean the Thread is not available for the Thread pool. This could have consequences for high load systems. So therefore I have two questions:
1) What would be the best way to implement this use case?
2) How much of a burden would using Thread.Sleep be for WSO?
Alternative solutions, for example using topic and stuff are also welcome :)
Hope you guys can help!
Answering the questions in the responses:
We are sending requests to an external system and an offline data store (ODS; DSS component of WSO2). The external system has precedense, but when it doesn't return within one second we want the ODS to answer the request.
Alternative paths:
- The ODS is offline, in this case the system has to wait for the external system for a longer time;
- The external system returns after some time, althought the ODS result has been send to the requester we still want the response of the external system to update our ODS.
We are currently investigating clone and aggregator.
When you say, Thread.sleep(), the first thing came to my mind is using a Class Mediator. This would be an easy way to write custom logic and add a sleep.
The sample for "Writing your own Custom Mediation in Java" will help you to learn the steps for writing a Class Mediator.
You need to copy the Jar containing custom mediator class to repository/components/lib/
When you use thread sleep inside your mediation logic, the request will hang for the specified time period.
This may impact your performance. But you should be able to tune the parameters for your needs.
It all depends on your requirements.
What needs to be done to make InMemoryTransientMessageService run in a background thread? I publish things inside a service using
base.MessageProducer.Publish(new RequestDto());
and they are exececuted immediately inside the service-request.
The project is self-hosted.
Here is a quick unit test showing the blocking of the current request instead of deferring it to the background:
https://gist.github.com/lmcnearney/5407097
There is nothing out of the box. You would have to build your own. Take a look at ServiceStack.Redis.Messaging.RedisMqHost - most of what you need is there, and it is probably simpler (one thread does everything) to get you going when compared to ServiceStack.Redis.Messaging.RedisMqServer (one thread for queue listening, one for each worker). I suggest you take that class and adapt it to your needs.
A few pointers:
ServiceStack.Message.InMemoryMessageQueueClient does not implement WaitForNotifyOnAny() so you will need an alternative way of getting the background thread to wait to incoming messages.
Closely related, the ServiceStack.Redis implementation uses topic subscriptions, which in this class is used to transfer the WorkerStatus.StopCommand, which means you have to find an alternative way of getting the background thread to stop.
Finally, you may want to adapt ServiceStack.Redis.Messaging.RedisMessageProducer as its Publish() method pushes the message requested to the queue and pushes the channel / queue name to the TopicIn queue. After reading the code you can see how the three points tie together.
Hope this helps...