Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 1 year ago.
Improve this question
I have a pretty standard Vapor http server, It has a middleware where it inspects the request body and does some authentication validation.
func respond(to request: Request, chainingTo next: Responder) -> EventLoopFuture<Response> {
var myStuff: SomeCommonPattern? = try request.content.decode(SomeCommonPattern?.self)
SomeCommonPattern is a base class for all other requests in the group.
That works very well in debug on Mac. When I run this in docker on my Mac laptop it still works as expected. I put it through a rigorous tests with a hundred clients making simultaneous requests for hours. Not a single failure. Now I moved the same docker image to a production machine, which is Ubuntu with lover specs than my machine, and my code still works with exception when it does not.
About 1 request out of 5 fails to decode the request. I put some additional logging and sure enough, sometimes request.body.string is empty when most other same requests are fine. Anyone knows what could be happening ? It looks almost like the body of the request is still in transit when the middleware is being called. It happens even when I make requests from a single client.
Edit: I just realized that on my laptop the service is running directly, while on the linux machine it is behind apache 2 reverse proxy. It is probably a significant detail but I still do not know the reason of the intermittent behavior.
Edit 2:
I moved the failing code out of the middleware and put in every endpoint implementation. It is much less convenient and more error prone but now my application works 100% of the time. That may confirm that apache is off the hook and the problem is indeed in Vapor, or my misunderstanding how to use it.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 months ago.
Improve this question
Some context:
I have little experience with ci/CD and manage a fast paced growing application since it saw the light of the day for the first time. It is composed by several microservices at different environments. Devs are constantly pushing new code to DEV , but they frequently forget about sending new values from their local .env ove to the openshift cloud, regardless of this being a brand new environment or existing ones.
The outcome? Services that fail because they lack to have their secrets updated.
I understand the underlying issue is lack of communication between both us DevOps staff and devs themselves. But I've been trying to figure out some sort of process that would make sure we are not missing anything. Maybe something like a "before takeoff checklist" (yes, like the ones pilots do in a real flight preparation): if the chack fails then the aircraft is not ready to takeoff.
So the question is for everyone out there that practices DevOps. How do you guys deal with this?
Does anyone automates this within Openshift/kubernetes, for example? From your perspective and experience, would you suggest any tools for that, or simply enforce communication?
Guess no checklist or communication would work for team that ...frequently forget about sending new values from their local .env ove..., which you must have already done.
Your step in the pipeline should check for service availability before proceeding to next step, eg. does the service has endpoint registered within acceptable time, no endpoint means the backing pod(s) did not enter readiness state as expected. In such case, rollback and send notification to the team responsible for the service/application and exit cleanly.
There's no fix formula for CI/CD, especially human error. Check & balance at every step is the least you can do to trigger early warning and avoid a disastrous deployment.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I am trying to build a small REST API for one of our clients, who was wishing for that kind of API. It's the first time I read into that topic.
Most of our services take quite some time for fully processing client orders. For that the client may create resources by POSTing xml data and retrieve results (much) later by GETting the corresponding resource. That was pretty straight forward.
Now though we want to create another service, which will typically evaluate results almost immediately and I really don't know, how to implement it with best practice.
Since the request can be processed immediately I want to avoid using two requests for creating and retrieving the resource. It just seems unnecessary and laborious.
On the other hand one single fitting HTTP request method does not seem to exist for this problem since POST requests shouldn't respond with anything but a response-code and GET requests should be independent from their body (today it seems to be possible to send body data with GET requests, nevertheless it seems to be bad practice and should not influence the response. In other words the server is only allowed to use information, which is contained in the URL).
Further I cannot send the data as query parameter in the GET-URL since the data contains very sensitive information - we have pretty strict laws regarding that topic in my country and I learned to be very careful .
What would be best practice for implementing such kind of responsive tool.
Is the REST API maybe the wrong choice anyway?
Thanks
POST requests shouldn't respond with anything but a response-code
This is not quite right.
In case of a POST that resulted in a creation, you should use a HTTP 201 status code and include a Location header that points to the URL of the new resource.
In addition, POST response may contain body with representation of the created object: 'Best' practice for restful POST response.
So the method POST is what you are looking for. It creates new resource and returns the representation of newly created object in the body.
If your service will modify objects after creation, it's up to you how to deal with it. If time of modification is very short, you can wait until object is modified and then return the object ready to use. Otherwise, you can return object with incomplete fields. Both approaches are RESTful.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 6 years ago.
Improve this question
I have 20 Rest API's build using Jersey and Apache Client.I want to know the max TPS my server can withstand, using JMeter tool.what is the best way to achieve such kind of performance scenario goal.
First of all build a Test Plan. I believe it should have at least 20 HTTP Request samplers to cover all your endpoints and a HTTP Header Manager to send correct Content-Type header. See Testing SOAP/REST Web Services Using JMeter article for details.
Once you have the Test Plan - run it with 1-2 virtual users to check that it does what it supposed to be doing. Inspect requests and responses details using View Results Tree listener. Modify requests if needed.
Configure your Thread Group(s) so load is increased gradually, i.e. provide reasonable Ramp-Up time
Once you're happy with your test behaviour disable the View Results Tree listener and run your test in non-GUI mode
Analyze the results using i.e. HTML Reporting Dashboard. The value which interests you lives in Hits Per Second graph
My problem is the infamous "StatusCodeException: 0" problem happening when using GWT 2.6.1 when accessing page via subdomain https://sub.site.com/.
Now, this happens quite sporadically for one customer using IE11 and I can't reproduce this from several distinct computers using IE11, IE10, IE9 or IE8 (not to talk about Chrome or Firefox).
Accessing exactly the same webapp from https://site.com/ seems to work fine for that customer.
This obviously lead me to conclusion that I'm having problem with Same Origin Policy.
What is strange though is that my webapp is designed in the way that no cross-domain or cross-subdomain requests are made. Same goes for no cross-protocol as well no cross-port requests. In other words, Same Origin Policy is not violated in this situation. As a confirmation of that, I can provide following proof:
While being at customer site I've seen how this is reproduced: customer starts using application and everything works fine - all requests are returning response normally. Then, after several minutes of working, exactly the same requests on the same page (without reloads) starts to fail with StatusCodeException: 0.
Basically, both https://sub.site.com and https://site.com points to the same IP, and there is only one Tomcat webapp serving exactly the same resources both for https://sub.site.com and https://site.com.
Another proof would be the codebase of the single GWT module itself: there I use only one instance of one service called DashboardService:
public class DashboardModule extends EntryPoint implements IDashboardModule {
private final DashboardServiceAsync dashboardService = createDashboardService();
#Override
public void onModuleLoad() {
// loading of module elements
// dashboardService is passed as a parameter so only one instance is used
}
/**
* PLEASE SEE QUESTION #1 BELOW CODE SNIPPET
*/
private static final String DASHBOARD_REQUEST_URL = "request";
private static DashboardServiceAsync createDashboardService() {
final DashboardServiceAsync service = GWT.create(DashboardService.class);
((ServiceDefTarget) service).setServiceEntryPoint(DASHBOARD_REQUEST_URL);
return service;
}
}
=================================== EDIT ====================================
After looking in the console at customer location, the error was always the following:
SCRIPT7002: XmlHttpRequest: network error 0x2ee4, ...
so it seems that this has nothing to do with Same-Origin Policy, because as per this article it is described as ERROR_INTERNET_INTERNAL_ERROR An internal error has occurred.
It's a pity, but I've found only 2 mentions of this error which were not resolved:
Error under IE10 and Error under IE11.
I have an assumption that customer is very probably accessing site through some proxy which slightly changes the requests and IE can't handle them.
Question 1: does anybody knows how can I simulate or reproduce mentioned error locally?
Question 2: does anybody knows how this problem can be gracefully worked around?
Question 3: is it ok to simply retry the request, or this request may have reached the server and modify it, so retrying it may produce duplicate modification?
Will try to setup forwarding proxy to simulate possible customer setup to at least reproduce mentioned error...
I greatly appreciate any help!
Ok, so after bugging with this problem for a workweek I finally managed to solve it.
Actually, I was able to reproduce very similar problem locally when I installed Apache2 server in front of Tomcat and accessed it from another VirtualBox Win7 host with IE11. This gave me sporadic StatusCodeException: 0 with Network error 0x2ef3 though but the behaviour was very similar: GWT-RPC requests started to fail after a minute or so. This was reproducable in IE10 and IE11 but working fine in IE8 and IE9 :) (is IE getting crappier with new versions?)
Locally I was able to fix that problem by simply disabling Keep-alive functionality for IE browsers by adding following lines to /etc/apache2/sites-enabled/default-ssl.conf Apache2 ssl configuration file:
# following line was added
BrowserMatch "Trident" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0
</VirtualHost>
</IfModule>
This basically tells Apache2 not to use keep-alive, use special SSL handling and generally downgrade to HTTP 1.0 standard whenever user-agent string in request has Trident word (matches IE11 and IE10 and possibly earlier IEs)
This added Connection: close HTTP header to each response and seemed to work fine locally.
On customers site this wasn't still working and produced the same Network error: 0x2ee4.
It may be worth noting that customer was using McAfee Web Gateway as forwarding proxy which stood in the middle of browser <-> server communication.
Long story short, I found out that the problem was in the following: when page loads there are multiple GET requests being sent to server to get the page, resources etc. Then after 10 seconds of using it (my webapp is single-page-application, so user may spend more than 10 minutes on same page) only GWT-RPC requests are being made to the server which are POST requests. And after a minute of using this page (I suspect 1 minute = keep-alive timeout of proxy server) these POST requests start randomly fail with 0x2ee4 network error.
After I implemented GWT-RPC retry functionality, I found out that after 30 seconds of retries simply ALL GWT-RPC requests fail with above error. Refreshing the page was solving this problem again for a minute or so and then same story happened.
So, I figured out that CRAPPY IE11 and IE10 are incorrectly handling combination of SSL, Keep-alive and POST requests. It seems that сrappy IE10 and IE11 simply can't renew keep-alive ssl connection using POST requests and only do this using GET requests.
Please note that Chrome, Firefox and other normal browsers are handling this situation quite well. When inspecting how Firefox behaves in such situation in Firebug: it can be clearly seen that POST request is made, then it is shown as aborted for like 0.5s and then this it is shown as successful (I suspect that Firefox handles this specific situation and makes GET request to server itself to renew SSL keep-alive connection and then retries POST request)
So, to fix this problem in IE I simply implemented functionality which "pings" server with GET request every 5 seconds (be ready to experiment with this time since this is most probably related to customer's proxy keep-alive timeout).
This made it work (please note that above Apache2 configuration hack is not needed in this case)
I really hope that this will help people with similar issue and save their time
Resources used:
IE Network Error 0x2ef3 question 1
IE Network Error 0x2ef3 question 2
IE Network Error 0x2ef3 question 3
Awesome q&a on how to implement transparent GWT-RPC retry functionality
P.S. Will I report this IE10 and IE11 issue to Microsoft? - really I'm not eager spending 30+ minutes of my time reporting issue on commercial crappy IE browser issue after I've already spent more than a week of finding out the problem.
I insist on recommending Chrome or Firefox or other normal browser to customers as viable alternative and I still think that IE11 is not suited for modern websites with AJAX
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I want to implement a simple in-house table that tracks user page views on my website. Without targeting some specific hypothesis, what is useful data to store? Eventually I'll use it to build graphs or decision trees to better learn about our user base. This is static (no javascript).
Things I can think of:
URL accessed
HTTP refer[r]er
HTTP Accept Language
Browser-agent
Session id
User id (if logged in)
Time visited
It depends on how public your site is. If your site requires authentication you can have more controlled statistics because you can trace the user (visitors) history. In the case the user does not require authentication you are limited to the information provided by the SERVER VARIABLES: HTTP_USER_AGENT; REMOTE_USER; REMOTE_ADDR; REMOTE_HOST; REMOTE_PORT; HTTP_COOKIE; HTTP_USER_AGENT.
I have implemented something like this for some non-public site each time the user logs on to the site, the information I'm storing looks like:
User Key
Remote host IP
Date Logon
Last Request Datetime
Total time connected (minutes)
Last Request Minutes
Event/Action performed
Sounds like a good start,
I'd be inclined to store visitor IP address, and derived from that via a geo ip lookup the location of the visitor.
Also you could consider reverse dns'ing the IP to get an idea of the isp you're user is on, you might never use it but then again it could be useful if you have a report of downstream caching causing problems.