Is there any way to make synchronous call of all the codes written inside the iterator mediator in esb wso2?
Finally, it is working by doing two things together.
Set sequential="true" in iterator and in call mediator use blocking = "true"
Are you using send mediator? If yes, use call mediator instead, which is synchronous.
Related
I have an API with 2 layers Controller and Service with Micronaut, Kotlin & Project Reactor. This application needs to handle requests in non-blocking manner.
I have a Post function makePayment method as below
fun makePayment(payment: Payment): Mono<PaymentDetails> in class PaymentController.
This calls a service class PaymentService which also has the same function as above.
This service internally uses io.micronaut.reactor.http.client.ReactorHttpClient to make the payment with Bank.
What is the right way to handle exception here?
Option1
reactorHttpClient.exchange().onErrorResume()
In onErrorResume I will map it to custom error code with suitable HTTP Status.No other specific Global Error handling is done.
Option2
Uses Controller Advise approach to have a Global Exception Handler with #Error(global = true) as mentioned below.
https://docs.micronaut.io/latest/guide/index.html#globalErrorHandling
I tried both approaches and both works.
I would like to understand what is the right approach considering Non-Blocking server and reactive streams approach.
Also does the Global Exception Handler with #Error(global = true) going to work like a Blocking or Non-Blocking way?
i need stream of a service gRPC with Wire and need use Flow on client, but executeBlocking() do not provide method with return via Flow, need implementation manual via flow emits?
I think you wanna use execute, instead of executeBlocking() and find some way to transform the Channels into Flows? Or just start a new Flow from the blockingGet value?
flow {
emit(value)
}
I need to invoke a custom java class using WSO2 esb. The class takes an input parameter as a string and returns the XmlObject from the method.
How to achieve this using WSO2 and which mediator to use for the same?
regards
Amit Pawar.
You can use custom class mediators to achieve this[1]. Within this mediator you have to call your method and then set the result to the message context as a property and obtain it down the line in the mediation flow.
[1] - https://docs.wso2.org/display/ESB480/Class+Mediator
You can also refer the sample in [1] to have a clear idea
[1] https://docs.wso2.org/display/ESB480/Sample+380:+Writing+your+own+Custom+Mediation+in+Java
I have WCF service which sends messages to its clients. I would like to call callback methods asynchronously. I have read this answer:
WCF asynchronous callback
But there is one problem. When I am generating IMyServiceCallback from WebServiceReference it contains both synchronous and asynchronous methods (while on the service side there is callback contract with only asynchronous methods - BeginCallbackMethod and EndCallbackMethod). What is more when I call from MyService to calback BeginCallbackMethod, on the client side (in callback implementation) it is using synchronous CallbackMethod. The question is why? Is there any way to configure it?
By default WCF will call the synchronous version of an operation if both sync and async are present; I don't know how (or if) you can change that logic, but one thing you can do is to simply remove the synchronous method from the generated callback interface. The callback code should continue to work, and it will use the asynchronous implementation instead. You can also just remove the [OperationContract] attribute from the synchronous version, to the same effect.
Regardind this solution Using the CCR with ASynchronous WCF Service
Why do you need to do this :
ThreadPool.QueueUserWorkItem(s => callback(this));
instead of just calling callback(this) ?
Isn't QueueUserWorkItem going to use yet another thread ?
"callback" is a method that needs to be provided as an input parameter to BeginGetAccount. In the answer it doesn't specify the "callback" method so there is no way to know if it makes use of a new thread or not and therefore it does make sense to put the "callback" method on a seperate thread in Complete.
If you could guarantee "callback" created its own thread then you wouldn't need to create one in the Complete method.