I have a spring boot project with websocket and I want to test the project sending multiple request to the socket from different users. I want to use threads to imitate the users that send data from the web app but I don't know exactly how to make the test. Can anyone help me, and show one simple test for an websocket using threads?
You can use JMeter for testing your websocket project.
For further reading:
https://www.blazemeter.com/blog/websocket-testing-apache-jmeter
http://www.baeldung.com/websockets-spring
Good example:
https://github.com/Fyro-Ing/JMeter-WebSocket-StompSampler
When writing a Spring Boot application using STOMP on websockets, I struggled a lot to find out how to configure a test client.
I ended up writing a little library called Jackstomp to make it easier to create type-safe tests for STOMP WS applications using JSON as message body.
I haven't used it with multiple threads, but you should be able to easily use it within each thread to create independent clients for each user and perform basic operations. (Please note that a different client should be used in each thread).
The point is that you can really express a synchronous flow for each client, including actively querying for received events.
Even if you don't use this library, you can look at the code to get a grasp of the different things to setup.
Related
Also if I have authorisation header fields-> Where and how do I give them?? Is there any tool for this?
I have done local host "ws://localhost:8080/socket" using
If you are using the "WebSockets Samplers" plugin with JMeter, you can open multiple websocket connections, but not at the same time on the same thread (JMeter user). If you are sure you need that feature, there is an experimental build of the plugin that supports multiple connections on one thread.
You can add authorisation fields by using the standard JMeter HeaderManager.
can anyone point me to a resource, how I can get spring-webflux and javamelody to work together?
Seems, that a servletcontext is neccessary for startup, which I don't have/need.
I'm aware of the coll metrics stuff, that comes with spring-boot 2.x, but I don't have anything to display the metrics with, and am locked to a company environment, where just installing something isn't a valid option.
Thanks,
Henning
javamelody is mainly based on monitoring of memory, cpu, http requests, sql requests and spring components among other things. See javamelody-spring-boot-starter for example.
But as far as I know, Spring webflux does not use the servlet api. So what do you want to monitor?
If you just want to have graphs in a browser, then start a http server for javamelody reports like in standalone. And if you also want to monitor sql requests and spring components, then add in your application all methods from this example, except monitoringSessionListener and monitoringFilter.
A new spring-boot-starter for javamelody in webflux could be created if it makes sense.
I am working on a project which has following requirements:
Perform sticky based load balancing(based on SOAP session ID) onto multiple backend servers.
Possibility to plugin my own custom based load balancer.
Easy to write and deploy.
A central configuration file(Possibly an XML), to take care of all the backend servers.
Easy extraction of a node from this configuration file(Possibly with xpath).
I tried working with camel for a while but, wasn't able to do perform certain task with it.
So thought of giving a try to Akka.
Will akka be possibly able to satisfy the above requirements?
If so is there a load balancing example in akka or proxy example?
Would really appreciate some feedbacks.
You can do everything you've described with Akka.
You don't mention what language you're working with, Scala or Java. I've included links to the Scala documentation.
Before you do anything with Akka you HAVE TO read the documentation and understand how Akka works.
http://doc.akka.io/docs/akka/2.0.3/
Doing so, you'll find Akka is perfect for the project you've described with some minor caveats.
Once you read the documentation the following answers should make a lot of sense.
Perform sticky based load balancing(based on SOAP session ID) onto multiple backend servers.
Load balancing is already part of the framework (it's called Routing in Akka http://doc.akka.io/docs/akka/2.0.3/scala/routing.html) and Remoting (http://doc.akka.io/docs/akka/2.0.3/scala/remoting.html) will take care of the backend servers. You can easily combine the two.
To my knowledge the idea of sticky load balancing is not a part of Akka but I can envision this being accomplished with a Map using the session ID as the key and the Actor name (or path) as the value. A quick actorFor will take care of the rest. Not well thought out but should give you a good idea of where to start.
Possibility to plugin my own custom based load balancer.
Refer to the Routing documentation.
Easy to write and deploy.
This depends on your aptitude and effort but after you read certain parts of the documentation you should be build a proof of concept in a couple of hours.
Deployment can be a bit frustrating mostly because the documentation isn't really great with respect to deploying Akka networks with remote components. However, there are enough examples on the web that you can figure out how to get it done...eventually. Once you do it once it's no big deal.
A central configuration file(Possibly an XML), to take care of all the backend servers.
Akka uses Typesafe Config (https://github.com/typesafehub/config) which is a lot easier to work with than XML (but I hate XML so take that with a grain of salt). As far as a central configuration, I'm not sure what you're trying to accomplish but it sounds like something that can be solved using remote actor creation. Again, see the Remoting documentation.
Easy extraction of a node from this configuration file(Possibly with xpath).
Akka provides a lookup method .actorFor. There's no need to go to the configuration file once the system is up and running.
If so is there a load balancing example in akka or proxy example?
Google is your friend.
I'm about to embark on configuring the ssl handler for our server. I have looked at the secure chat example a few times. I'm just trying to formulate how I can write a unit test using the embedder testing classes.
Does anyone have a netty unit testing example for the ssl handler setup? I was wondering if anyone would like to share their efforts in this area. I'm still not sure how to begin.
Many thanks.
I've had to do unit tests for Netty handler pipelines that included StartTLS and compression. I found it easier just to use a loopback socket rather than try to wire up the encoder/decoder embedders.
I did use the embedders for the more isolated tests dealing specifically with individual encoding and decoding handlers but when testing the full pipeline I think a loopback socket is the way to go.
I want to communicate xml serialized objects from the server to the client and the other way arround. Now it is (probably) easy to invoke methods from a mobile client (compact framework) using WCF, but is there a way so that the server can invoke methods on the client side or some other way to pull data from the client? I know that callback contracts are not available in the compact framework as you can see here: http://blogs.msdn.com/andrewarnottms/archive/2007/09/13/calling-wcf-services-from-netcf-3-5-using-compact-wcf-and-netcfsvcutil-exe.aspx
Originally I thought of socket programming and of developing this by myself, then someone here mentioned WCF. But it seems like WCF only would work in a non mobile environment as I need callbacks.
Anyone can help me with this? Is it possible to develop a two way communication with a desktop server and multiple mobile clients using WCF, or will I have to do socket programming?
Thanks for any advice or any kind of help!
at ctacke
Thank you for your help. I actually stumbled across your Padran web server before.Havent really checked it out yet. But I definitely will do that later on. Anyway, a socket solution does not seem that bad at the moment. In the meanwhile I figured that it is quite easy to send data from multiple clients to a 'socket server'. If I can manage those connections somehow I can send data back to the clients. And then I would have to come up with some kind if protocol which handles the data or commands I send over the network... I guess the hardest part would be to make up such a protocol as I do not have a clue about that atm...
Even if you go to sockets it might be a bit difficult due to routing, carrier filtering and NAT translations (you've not mentioned what your actual network topology is). This is the reason that most mobile applications have to poll the server, even if it is a "push" paradigm (like Exchange's push mechanism, where the client actually polls).
Generally speaking, unless you're on something like a local wireless network where you have solid, routable, unfiltered network access, the client should periodically call the server and ask if the server has data. If it does, then it pulls the data from the server.
EDIT
Now that we know a little more about your topolgy from your comment, I can steer you a little more. Unfortunately Microsoft has not made it easy for Windwos CE devices to host services (WCF or otherwise). There is, in theory, the required infrstructure to build up your own WCF channel and actually host a service, but it's not a trivial task. I looked into it quite some time ago and figured it was a couple months of work and that would have been with the assistance of someone in Redmond that knew how the existing Exchange channel works.
Personally I'd opt for hosting a REST-based web service using our Padarn web server because it's simple to do and I've done it for quite a number of clients now. I realize that it's a little self-serving to propose Padarn as a solution but the entire reason I implemented custom IHttpHandlers in Padarn was because I couldn't find anything else out there that really provided any easy way for a CE device to host it's own services and it's a problem we often have to provide a solution for.
The other options would be things like a proprietary socket solution, hosting an FTP server on the device, using the (abhorrent, IMO) MS-provided HTTP server with ISAPI, Telnet or something along those lines. All of them seem either a hack, a lot of work or both.