We are trying to figure out if we can copy each http request coming in to our tomcat production server and send it to a development test server to get a real simulation of the production traffic.
The original request handling should not have any impact. The production server need not wait for a response for the copied request from the development server.
Is there a simple way to do this?
If you really want to do it live, what I'd recommend is to put a Http Servlet Filter in front of your production webapp. In this filter, copy the request data into a new request and send it (asynchronously) to your development server. This way, at least you don't have to modify your application code.
But it think you should try to avoid doing that in a production environment. Instead, you could dump the request data (see Istvan answer) and do the request from a development machine.
Not that I know of. Maybe you can setup http://tomcat.apache.org/tomcat-7.0-doc/config/filter.html#Request_Dumper_Filter in a way that it sends the logs to a remote server that has some small app playing back the requests based on what's received.
"sends the logs" = configure log4j so that it stores the log on a network share or use socketappender
Related
I have 2 services - Ingress (input node) and Storage.
Client send requests on Ingress to get some data (large files).
Ingress send request to Storage to get data that Client needs.
Maybe, somebody can tell what I can use to restream response from Storage to Client without OutOfMemory issues.
Now I've implemented it as saving result in file on Ingress, rereading it and sending as response to Client. But it works really slow, of course.
Thank you.
Spring Cloud Gateway (more documentation here) can help. It's primary purpose seems to be as a configuration-driven gateway, but it can be embedded into an application to serve just certain endpoints; so you may be able to configure it in your "Ingress" service to route certain requests to your Storage service.
If that doesn't work (or, as was in my case, it's too much work), you can use some specific classes from Spring Cloud Gateway in your own service. Specifically, I've used the ProxyExchange class to proxy calls to another service and stream the results back to the original caller.
I am working on a web application, which is deployed to weblogic cluster. Upon user invoking an action in jsp, at the server side we make an outbouond call (with 2-way ssl) to an external service. This service returns me some data, which we send to the client side for rendering on UI. This flow is working as fine.
Outbound request for 2-way SSL are made from a utility class within the application, using java.net.URLConnection. However, upon checking the access.log for weblogic, I don't see these outbounds call logs in the access logs.
Now, business has Access log monitoring software in place, to monitor specific urls/reponse code and alert IT team if the number of non-200 responses crosses some threshold.
So, the challenge I am having currently is, how to log the outbound request's url & response status to the access log of weblogic server. I have been googling over the net, but couldn't find anything so far which can suggest how to go about it. I am new to weblogic, so not sure if this is possible OOTB or I need to write some custom code for this.
Need advice from weblogic experts out there. Thanks in advance!
Weblogic only traces incoming http/s requests in its access logs. Your application is responsible for logging its own outbound requests in its own logs. Do not log your entries in weblogic's logs.
I have separate application for client side which is in ReactJs and NodeJS (Express server) and Web Services in Java application running in tomcat.
My query is which is better approach in terms of making web service call.
One is making direct web service call from ReactJS and get the data.
Other one is calling web service in Express server. Request from client browser will go to Express and Express will make all web services call.
I know one issue in making direct call to web service will be cross domain policy which can be handle by setting configuration in Java server.
Apart from it what should be better approach.
From my experience it ended up better using direct calls from UI application and avoiding intermediate server.
Reason for doing this directly is that our servers ended up with a lot of restrictions based on IP addresses, and all requests have been coming from intermediate server (nodeJS server), so DDOS protection of end server had to have some exceptions (our node server which could be on ACS with dynamic IP addresses so it might be hard to manage).
Also If you want to pass and track end users IP addresses, you need to manage headers on Node server (to be sure you are passing it as it was in original request).
It is way simpler to manage this kind of situation if calls are comming from React app and simply set up CORS on java server.
Also its way easier to debug it on UI app directly, so you will be watching response logs on one place only. Other way around you could end up debugging your node server and UI app.
Hope this helps a bit.
Best way IMO is to create a router in Node js specifically for all your Java webservices and act as a proxy.
Suppose if your url pattern is like http://domain/java-ws/api then all these requests will be routed to your Java service.
If you have an Apache server directing requests to your node JS then configure url pattern proxy using proxy module.
Browsers are blocking CORS requests for a reason. You may get away by setting things on your server.
This question might sound a bit abstract,answered (but did my search didn't stumble on a convenient answer) or not specific at all ,but I will try to provide as much information as I can.
I am building a mobile application which will gather and send sensory data to a remote server. The remote server will collect all these data in a mySQL database and make computations (not the mysql database ,another process/program) . What I wanna know is :
After some updates in the database , is it doable to send a response from a RESTful Server to a certain client (the one who like did the last update probably) ,using something like "a background thread"? Or this should be done via socket connection through server-client response?
Some remarks:
I am using javaEE, Spring MVC with hibernate and tomcat (cause I am familiar with the environment though in a more asynchronous manner).
I thought this would be a convenient way because the SQL schema is not much complicated and security and authentication issues are not needed (it's a prototype).
Also there is a front-end webpage that will have to visualize these data, so such a back-end system would look like a good option for getting the job done fast.
Lastly I saw this solution :
Is there a way to 'listen' for a database event and update a page in real time?
My issue is that besides the page I wanna update the client's side with messages from the RESTful server.
If all these above are unecessary and a more simple client-server application will prove better and less complex please be welcome to inform me.
Thank you in advance.
Generally you should upload your data to a resource on the server (e.g. POST /widgets and the server should immediately return with a 201 Created or (if creation is too slow and needs to happen later) 202 Accepted status. There are several approaches after that happens, each has their merits:
Polling - The server's response includes a location field which the client can then proceed to poll until a change happens (e.g. check for an update every second). This is the easiest approach and quite efficient if you use HTTP caching effectively and the average number of checks is relatively low.
Push notification - Server sends a push notification when the change happens, report's generated, etc. Obviously this requires you to store the client's details and their notification requirements. This is probably the cleanest approach and also easy to scale. In the case of Android (also iOS) you have free push notifications available via Google Cloud Messaging.
Set up a persistent connection between client and server, e.g. using a Websocket or low-level TCP connection. This should yield the fastest response times, but will probably be a drain on phone battery, harder to scale on the server, and more complex to code.
could you please give me a sample code on how an Http Server(Java) receives the request of a client(android)? I mean the client sends the request via Httppost, how the server takes the content of these requests in order to see the context and reply? I am trying to built a chat application.
Thank you in advance!
The server-side of HTTP is usually implemented using the protocol stack provided by a web container. You would then implement your application's server-side as servlets. There are numerous tutorials on this.
If that's the way you want to proceed, look at one of the standard web containers; e.g. Tomcat, Jetty, Glassfish, etc. The source code for all of these is available for you to browse, though I should warn you that they are all complicated under the hood.
Assuming that your HTTP service is going to be delivering JSON or XML (rather than HTML) to clients, you may want to look into using a RESTful framework.
Have a look at ServerSocket. Keep in mind that accept() blocks and, as you will probably run it in a service, you will want to time it out and check for the completion of the service. That should probably run in its own thread as should the responders to requests.
From there, you can open input and output streams to receive the request and write the response. There are any number of packages that can help you with the interaction, or you can roll your own, but it doesn't seem like you've done a lot of homework. Perhaps some searching, reading, and more specific questions would more you along more quickly.