I have extracted the authorization token after running my login API successfully. And it can be used within the same thread while I'm configuring different HTTP requests.
But I want to create a separate thread for rest of my APIs and use the authorization token which I extracted already. How can I do it in Jmeter?
According to JMeter Documentation:
Properties are not the same as variables. Variables are local to a thread; properties are common to all threads
So you can pass it in 2 ways:
Using __setProperty() function in 1st Thread Group (or thread) to store the value into a JMeter Property and then use __P() function to read it back where required.
Using Inter-Thread Communication Plugin if your logic is more complex
Related
I am new to spring webflux. I am trying to implement the ThreadLocal using spring webflux.
I have a requirement where I need to pass the header from one microservice to another microservice in webclient.
I do not want to pass the header from on service to another service carrying it manually and assigning it in each request.
So thought of using ThreadLocal when I can set it and can access that in webclient call.
I am try to find a sample application where I can refer ThreadLocal with in spring webflux.
You should not use ThreadLocal in reactive environment. Webflux (which based on Reactor) is a non blocking framework. It reuses threads so the steps of one reactive pipeline can run in different threads and also multiple requests can use the same thread concurrently - until one waits, another operation will be picked and executed. Imagine if your request puts something into threadlocal and waits - for example - on a db select, another request can override this value and the next pipeline stage of the original request will see that new value belongs to another request. Threadlocal is good for request-per-thread model.
For webflux, you can use contexts. For example put the value into the pipeline in a WebFilter, then you can retrieve it in any point of the reactive pipeline:
chain.filter(exchange).contextWrite(<your data>)
In the pipeline (in map/flatmap...)
Mono.deferContextual(...)
Here is the link for documentation.
Alternatively you can lift ThreadLocal's value on every operation using Hooks, but this is not a nice and bulletproof solution.
I have created a spring boot rest client, which basically consumes a rest service. I want to write a junit test case to validate my rest client. I was hoping to intercept the rest request somehow in the junit test case and check if the context in the URL, path parameters, query param and body is correct. i just want to confirm, if anyone uses the rest client, it will make the proper calls to the rest services.
Here are some approaches you can try:
Use #RestClientTest annotation. It will load only the class that contains rest client calls and also configures the application context during the test to provide ways to match the request for verifications.
You can read this article for example
Use WireMock - you can start it at during the setup phase setup the expectations, during the test make the calls and at the end verify that the calls have matched the expected ones. When you make the request to wire mock it will "record" it and store in memory (until you reset it). It also starts on the real port so you should have a port available. For more information read this chapter of the official documentation
I am using Crossbars dynamic authorization to authorize all RPCs in my application.
Is it or will it be possible to access the arguments of the RPC in the authorizer?
It might be possible to solve the issue by utilizing "pattern based registrations". The argument can then be moved into the URI to be examined by the authorizer.
For example the protected resource can register com.example.user.*.delete and when the procedure is called with com.example.user.123.delete - the authorizer will be able to extract the user ID from the URI.
This is documented in the WAMP spec and also in the documentation for Crossbar.io
Accessing the arguments of the RPC is not possible. Dynamic authorization is there to work on the level of the data contained in the configuration, not application payload. If you want to do authorization based on the payload, then this needs to be triggered from the side of the callee.
Let say I get a inbound variable from an http connector when I use this URL
http://x.x.x.x:8080/post?post-message=Hallo wold.
How can I use the value of the #[header:INBOUND:post-message] accross the complete flow from after the HTTP connector all the way up tp the end. Should I use the Mule Object store to write it to ram?
This post shows the scope of variables but it seem there is not one thay can flow from start to en like a session bean
https://m-square.com.au/mule-school-the-mulemessage-property-scopes-and-variables/
Kind Regards.
If you need the variable available throughout the whole flow (and
other flows reached through a flow-ref) use the invocation scope
(set-variable to set, flowVars[] to read it)
If you need it to reach other flows through a transport (e.g. VM) put
it in the outbound or session scope.
If you need it to live as long as the app is running, through
different calls, use the Mule registry (volatile, only available as
long as the app is up) or the object store (which can be configured
as persistent, to hold state even if the app goes down).
Mule Session variables are good enough to get the value throughout application.
But if you need to use the value outside your application, then you can set mule outbound properties.
There are three type of scope level variables supported by mule .
You can use flow variable if you want the variable to be accessible throughout the whole flow.
You can use session variable if you want it to be accessible form other flows through a transport barrier.
Refer this blog for getting better understanding of how different types of variables are propagated between different mule flows.
http://blogs.mulesoft.com/dev/anypoint-platform-dev/mule-school-the-mulemessage-property-scopes-and-variables/
I'm storing some data as session variables in a mule flow that involves a mid-flow http call to an external service. I need this data for a subsequent branch of the flow logic, hence the session variable. However, I do not want this data to go out with the http call as http headers. Is there a way to limit which session variables mule includes as http headers in a given call?
If you want to decide what session property to propagate you can write a custom session handler and inject it into your http connector something like this:
<http:connector name="httpConnector">
<service-overrides sessionHandler="your_session_handler" />
</http:connector>
An example of a custom session handler can be found here
That said I'd like to echo David Dossot's answer: session variables should seldom be used, especially knowing how Mule leaks them by default. If you want to propagate something, you should set it explicitly as an outbound property and mule will propagate it.
Use flow variables: session variables should seldom be used, especially knowing how Mule leaks them by default.
Flow variables (aka invocation properties) should be unaffected by endpoint interactions, this by design. Any other behaviour would be a bug. If your variables do not need to extend further than a flow, use flow variables, not session variables.
session variables are not sent across http calls, only session ID is sent via cookie (usually)
if you need to pass some data via http call to external domain - include them in GET, for example, as cookie are not shared