Im new to hystrix..going through the below link
https://github.com/Netflix/Hystrix/wiki
so even if the dependencies(dependency services) are isolated by running in seperate threads and not allowing the failure dependency to use the resource(ex:tomcat) ,the user requests on the application will fail even any of the dependency service is down right..
im not clear how this solves the problem of reducing down time of the application..
Please clarify...correct me if im wrong
You do not have to wait for a dying endpoint. You can add fallback to get around the issue of not having an available healthy endpoint. Hystrix will keep on probing at predefined rate to check if service is back up and ready to serve in reasonable amount of time.
Related
Facing the below issue continuously with one POST request which is triggered from Google Cloud Task. The node application is deployed on Google App Engine. tried even increasing the instances but no luck.
Process terminated because the request deadline was exceeded. Please ensure that your HTTP server is listening for requests on 0.0.0.0 and on the port defined by the PORT environment variable. (Error code 123)
Any help would be useful. Thanks in advance
I have run into this issue in the past. The question, as posted, doesn't have enough information to narrow down the issue, but here are a few things you can try:
Increase memory size: It's possible that your instances are running out of memory and failing to start. Try increasing memory size of the instance to see if that helps.
Billing: Make sure all of your billing information is up to date and the issue isn't related to cost.
Warmups: Do you have a warmup, liveness check, or readiness check turned on? If so, make sure they are working properly.
Add Logging: The request has no logs displayed. You should try adding logging.info(...) statements in your code to see how far it gets before failing.
I have appengine endpoint and trying to reduce latency on few first calls to newly created endpoint instance. Application is written in Java and endpoints are auto scaled.
To address this issue I configured idle instance, although even if instance is already created, first few calls routed to it consume some extra time. Following documentation I've implemented the custom servlet handling warm up requests and marked the EndpointsServlet as load on startup.
Inside the warm up servlet I've put code that initiates some commonly used services, load some data etc. Effect was almost impossible to notice.
After it I have implemented calls to methods exposed by the endpoint like that:
call("/_ah/api/teamly/v1/test/dummy")
It works for some cases (even most of them) and after calling few key methods instance is really ready to serve. The problem I'm facing now is that if I'm using auto scaling for some module I can't route the request to specific instance.
So the question is:
How should I properly warm up the endpoint instance to avoid load requests initiated from frontend.
You need to put a listener to /_ah/warmup and then make calls to any resources you want it to be warmed up. You can find detailed information at:
Configuring Warmup Requests to Improve Performance
I'm using OSB 12c.I have an OSB proxy, which takes 15 minutes to complete each request on an average.
Lets say that I have five request now in running state.
Is there a way to see these running requests just like we can see the requests of bpel in EM console ?
Is there a way to terminate one of the requests without any impact on rest of the running requests ?
Is it possible to kill all request in case point-2 is not possible ?
Thanks !
I don't think so, not without changing things.
If you were open to changing the service to e.g. decompose the request into separate internal JMS messages, you should be able to use JMX to interrogate the MDBs and discover what they're up to. Then again, if you were to switch to JMS you could probably just look at the queue and get an idea about what it's doing just from the number and content of the messages created.
I'm not aware of the ability to cancel individual requests in OSB, sorry.
I think you can not terminate OSB threads directly.
You can configure your Weblogic to deal with stuck threads. (Thread that were running for a certain period of time)
You can configure a Dispatch Policy in your proxys using Work Manager to handle Stuck Threads and minimize impact on server.
The OPTION/POST Request is failing inconsistently with a console Error as err_timed_out. We get the issue inconsistently, it's only observed sometimes. Otherwise the request gets proper response from the back end. When it's timing out, the request doesn't even reach the server.
I have done some research on the stuff and found that due to maximum 6 connections to a resource restrictions it may wait for getting a connection released. But, I don't see any other requests pending ,all the other requests were completed.
In the timeline I can always see that it stalled for 20.00 seconds. Most of the time the time is same. But, it only shows that its been stalled for some time nothing else in the timeline.
The status of the request shows failed ERR_Connection_Timed_Out. Please help.
The Network Timing
Console Error
I've seen this issue when I use an authenticated proxy server and usually a refresh of the page fixes it.
Are you using an authenticated proxy server where you are seeing this behavior? Have you tried on a pc with direct access (i.e. without proxy) to the Internet?
I've got the same problem when I choose another ISP. I thought I would have only to put my new ID and password, but it wasn't the case.
I have an ADSL modem with a dry loop.
All others services were fine (DNS resolution, IP telephony, FTP, etc).
I did a lot of tests (disable firewall, try some others navigator, try under Linux, modem default factory, etc) none of those tests were successful.
To resolve the problem ERR_TIMED_OUT, I had to adjust the MTU and MRU values. I put 1458 rather than 1492, which is the default value.
It works for me. Maybe some ISPs use different values. Good luck.
I use NLog's WebService target in Silverlight and run into a problem if the logging service is unavailable.
What happens is that all calls to the logging service hang for a long time until they time out.
This is firstly ugly and secondly problematic in the face of a request limit, which I have under my given circumstances. After the request limit is reached due to several pending logging requests, the application also fails to make requests that are not logging related.
Ideally I'd like a WebService target that sends the requests sequentially, but I can't configure it to do that, can I?
Since I have full control about the logging server I could also move to a different target, but I'd rather have a purely configuration-based solution.
Some time back I implemented a logging target like that for Silverlight. We were using Common.Logging for .NET and it did not support Silverlight. So, we ported part of Common.Logging to Silverlight and implemented a "logging service adapter" to send our logging messages to a logging service. I implemented a logging queue using the producer/consumer pattern. Maybe you will find it useful.
In the end, the project that I was working on when I implemented this didn't go anywhere, so this particular piece of code is not in use.
Using WCF service via async interface from worker thread, how do I ensure that events are sent from the client "in order"