I am planning to use the hystrix command to make remote http call (httpclient). If the call fails for whatever reason, i want to fallback on another http call lets say I do it in fallbackMethod1(). If fallback http call also fail I want to fallback to static response fallbackMethod2(). How can I achieve it?
One way I can think of is to call another Hystrix command from fallbackMethod1 and have fallbackMethod2() as fallback in that command. Not sure if it's right way. My major concern is performance I may get 10k request per minute in my caller service.
My understanding was correct and netflix itself suggest to use another hysterix command inside fallback. Below is snippet from https://github.com/Netflix/Hystrix/wiki/How-it-Works
If you must use a network call in the fallback, you should do so by means of another HystrixCommand or HystrixObservableCommand
Related
I have a fundamental question regarding routing in Camel. Assuming I have this following route:
from(amq:MyQueue).process("jmsToHttp4").to("http4://dummyhost:8080").to("file://out/MyFolder");
Assuming that the http4-Response is just a String "Your Response". As far as I understood the documentation, "Your Response" can be retrieved through:
exchange.getOut().getBody()
Lets say that I only want to write "file://out/MyFolder", only if the reponse contains the word "Response". How can I achive this?
One more question:
If I want to write a test in a spring environment, how can I mock the response with "Your Response positive test" and "Your negative test"? Somehow I need to be able to write the response strings in the exchange.out.body right?
Thank you,
Hadi
One option would be to declare a .filter(body().contains("Response")) right after the HTTP call.
As for the test, you might use the mock component that offers you ways of processing the exchange and also asserting whatever you need when the message hits your mock endpoint.
There is actually some alternatives to test... I'm used to declaring the endpoints in the properties file and using the key in the class, e.g. .to("{{my.http.target}}"). Thus, in this case, in the test environment (dedicated properties file) you'd replace your http4 with mock.
In my opinion, it is cleaner and requires less control of the context when writing tests, mainly in big/complex applications. On the other hand, this might affect code readability.
But if you prefer to keep declaration in your Java class, you'll have to intercept the http4 call in the test env, then divert it to your mock endpoint.
I hope it's helpful.
I have created a route that via a splitter does multiple lookups, aggregates the responses and returns the list of objects.
I use a remote proxy to invoke the route.
Given that there are multiple branches on the route it is possible that some will succeed and some will fail. How can I get all the returned results but also a list of failures, with reasons for failures, from the remote proxy?
I can think of 3 options, but hope there is something cleaner
Use a header structure that is passed in with remote proxy call to collect errors
Wrap the return value of the remote proxy in structure that contains results and errors
Route errors to some error endpoint (not sure how to correlate with my request though)
Are there any other options?
I would go with option 3. Route all the errors to a generic error endpoint where you log the errors and return some default response. That way you can refer to that generic error endpoint from all your branches ensuring they will all react the same way whenever they encounter an error.
You should be able to get exception details in Aggregation strategy class and accordingly take action.
It depends on what you want to achieve from overall design. As a general practice, if you want consumer of your remote practice to fail on errors, it should get the exception details immediately. If your remote proxy is a REST Endpoint, it can return with 500 error. And similar strategy can be followed for other protocols.
With the "traditional" web framework, one could use e.g. AbstractRequestLoggingFilter for implementing a generic logging filter. With web-reactive the filter isn't called anymore (what makes sense, since it operates on HttpServletRequest).
Can anyone point me into the right direction for implementing a request filter with web-reactive, which logs the HTTP request, including its body, before and after the request like in AbstractRequestLoggingFilter?
You can implement a WebFilter and declare it as a bean, it will be picked up automatically.
Note that the WebFilter contract is based on ServerWebExchange, which holds a ServerHttpRequest. The body is not accessible directly as byte[], but rather as a Flux<DataBuffer>; this is not meant to be buffered in memory or consumed by the filter, so logging the whole request body is more complex than in MVC scenarios. Also, you should avoid blocking operations during request processing.
I've never heard this question answered clearly- "Is angularJS's $http a push or pull mechanism?"
Update: Due to the comment I've received, I've modified the question to make it clear that my question is not about what $http actually does via TCP. I'm concerned with the way in which $http relates to the digest cycle.
Further clarification:
option #1: $http is used pull mechanism manner (like a suspect it is) and it calls the assigned REST API when it is provoked (perhaps on every digest cycle?).
option #2: $http uses a push mechanism, which means that $http has to rely on server APIs that are smart enough to push updates to each and every subscriber. I doubt that this is the case, but I wanted to ask.
P.S. I plan on running some tests to discover this answer myself, but I wanted to get some scholarly thoughts from all you fine people.
$http is a service that allows sending AJAX requests when you call it. It does not call a REST API at each digest cycle as you claim it does. And it doesn't receive any notification from the server.
You don't need to write any test to discover this. Just read the documentation.
I suspect it's never been "answered clearly" because it isn't really ambiguous.
It makes HTTP calls, period. You don't push from the server using a client call.
I've been working on a REST implementation with my existing Cake install, and it's looking great except that I want to use HTTP Digest Authentication for all requests (Basic Auth won't cut it). So great, I'll generate a header in the client app (which is not cake) and send it to my cake install. Only problem is, I can't find a method for extracting that Digest from the request...
I've looked through the Cake API for something that I can use to get the Digest Header. You'd think that Request Handler would be able to grab it, but I can't find anything resembling that.
There must be another method of getting the digest that I am overlooking?
In the meantime I'm writing my own regex to parse it out of the Request... once I'm done I'll post it here so no one has to waste as much time as I did hunting for it.
Figured it out. It's already accessible via PHP as $_SERVER['PHP_AUTH_DIGEST']
So then you pass to parseDigestAuthData($_SERVER['PHP_AUTH_DIGEST']);
<bangs head against wall>